phpEnv中MySQL表名大小写敏感由lower_case_table_names决定：值为0时区分大小写（User≠user），值为1时不区分；需执行SHOW VARIABLES LIKE 'lower_case_table_names'确认，修改后必须重启服务且不可动态更改。
phpEnv 是 Windows 下的本地开发环境套件，它默认使用 MySQL 5.7 或 8.0（取决于版本），但其 MySQL 实例常以 lower_case_table_names=0 运行（即区分表名大小写）。当你从其他环境（如 Laravel 项目、Docker、或 Linux 开发机）直接复制 SQL 文件或迁移代码进来，就极容易触发 ERROR 1146 (42S02): Table 'db_name.table_name' doesn't exist——不是表真丢了，而是名字“对不上”。
检查 phpEnv 中 MySQL 是否区分表名大小写
phpEnv 的 MySQL 配置通常不显式声明 lower_case_table_names，此时 Windows 下默认值为 1（不区分），但若你手动改过配置、或升级过 MySQL 版本，可能变成 0。一旦设为 0，SELECT * FROM User; 和 SELECT * FROM user; 就是两个不同的表。
- 登录 phpEnv 自带的 MySQL（例如用 phpMyAdmin 或命令行）执行：
SHOW VARIABLES LIKE 'lower_case_table_names'; - 结果为
0：表名严格区分大小写，User≠user≠USER - 结果为
1：不区分，但建表时用大写命名的表，文件系统里仍生成小写名（InnoDB 表结构实际存于ibdata1，物理文件名不反映真实逻辑名） - 注意：修改该变量需重启 MySQL，且不能在已有数据的库上从
1改为0，否则直接启动失败
确认表是否真的存在（而非拼写/大小写错）
别急着重建表，先验证它“在不在”。phpEnv 的 MySQL 数据目录一般在 phpEnv\MySQL\data\ 下，每个数据库是一个文件夹；但 InnoDB 引擎的表数据并不全在那——关键元数据和行记录都在 ibdata1 里。所以光看文件夹里有没有 user.frm 或 user.ibd 不可靠。
- 执行：
USE your_database_name;确保已切换到目标库 - 执行：
SHOW TABLES;——注意输出里的真实表名（包括下划线、驼峰、全小写） - 如果没看到你要的表，再查一次：
SELECT TABLE_NAME FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_database_name' AND TABLE_NAME LIKE '%user%'; - 如果结果为空，说明表确实不存在；如果返回
users但你写的是User，那就是大小写问题
修复因 phpEnv 复制/重装导致的 1146（ibdata1 缺失）
很多人重装 phpEnv 后把旧的 data\ 文件夹整个拖进去，却漏了根目录下的 ibdata1。这个文件是 InnoDB 共享表空间核心，没了它，哪怕 .ibd 文件都在，MySQL 也“看不见”那些表——报错就是 1146，而不是更明确的崩溃或权限错误。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
立即学习“PHP免费学习笔记（深入）”；
- 关闭 phpEnv 的 MySQL 服务（务必完全停止，任务管理器里确认无
mysqld.exe进程） - 找到旧环境完整的
ibdata1（通常在原 phpEnv 安装目录根层，和bin、data同级） - 把它覆盖到新环境对应位置（不要只复制
data\your_db\下的文件） - 重启 MySQL —— 如果启动失败，大概率是
ibdata1和当前 MySQL 版本不兼容（比如旧版 5.7 的ibdata1直接丢进 8.0 环境），这时只能导出 SQL 再导入 - 验证：连上后执行
SHOW TABLES;，正常应列出全部表
ORM 或框架里表名写错的典型表现
phpEnv 常配合 ThinkPHP、Laravel、CodeIgniter 等使用。这些框架多数默认把模型类名转成小写加下划线（如 UserProfile → user_profile），但如果你手动指定了 $table 属性或 protected $table = 'UserProfile';，而数据库里实际是 userprofile，就会 1146。
- Laravel 中检查
app/Models/User.php的protected $table = '...';是否与SHOW TABLES;输出一致 - ThinkPHP 检查模型类中
protected $name = 'user';（不是$table） - CodeIgniter 检查
$this->load->database(); $this->db->get('user');中的字符串是否小写 - 临时加一句
echo $this->db->last_query();（CI）或DB::getQueryLog()（Laravel）看最终执行的 SQL 是什么
最麻烦的情况是：表名没错、ibdata1 也在、lower_case_table_names 也对，但还是 1146。这时候得怀疑 MySQL 用户权限是否被 phpEnv 的初始化脚本限制了——比如只给了 test 库权限，而你连的是 myapp。用 root 登录后执行 SHOW GRANTS FOR CURRENT_USER;，确认权限范围覆盖目标库表。
