MySQL 表名大小写由 lower_case_table_names 变量决定，PHP 不参与控制；推荐统一使用小写字母加下划线命名以保障跨平台兼容性。
MySQL 在不同操作系统下对表名大小写的处理机制
PHP 本身不控制建表时的大小写，真正起作用的是底层 MySQL 的 lower_case_table_names 系统变量。这个变量决定了 MySQL 如何存储和比较数据库名、表名（但不影响列名）。它的值在 MySQL 启动时读取，运行中不可修改。
-
lower_case_table_names = 0：区分大小写（Linux 默认），CREATE TABLE User和CREATE TABLE user是两张不同的表 -
lower_case_table_names = 1：不区分大小写，所有表名转为小写存储（Windows/macOS 默认） -
lower_case_table_names = 2：表名按创建时的大小写存储，但比较时转为小写（仅 macOS 支持）
PHP 的 mysqli 或 PDO 只是把建表语句原样发给 MySQL，不会做大小写转换或校验。所以“PHP 控制建表大小写”本质是误传——你得去配 MySQL，不是 PHP。
PHP 中用 PDO 或 mysqli 执行建表语句时的大小写注意事项
即使 MySQL 设置为不区分大小写（lower_case_table_names = 1），你在 PHP 里写的 SQL 语句中表名大小写仍需保持一致，否则容易引发可维护性问题或跨环境故障。
- 如果本地开发用 macOS（默认
=2），而生产用 Linux（默认=0），SELECT * FROM User在本地能跑，在生产可能报错Table 'db.User' doesn't exist - PDO 的
PDO::ATTR_CASE只影响字段名（column name）的大小写映射，对表名完全无效 - 用反引号包裹表名（
`User`）也不能绕过系统级大小写规则，只用于避免关键字冲突
CREATE TABLE `user` ( id INT PRIMARY KEY, name VARCHAR(50) );
上面建的是 user 表，不是 User；反引号不改变存储形态，只保留字面量解析。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
立即学习“PHP免费学习笔记（深入）”；
如何让团队建表命名统一且跨平台安全
最稳妥的做法是：**全部使用小写字母 + 下划线**，并写进团队规范。这不是风格偏好，而是规避 lower_case_table_names 差异带来的部署失败。
- 禁止出现
UserInfo、USER_LOG、ArticleList这类混合命名 - 建表语句中所有表名、字段名、索引名都强制小写（如
user_profile、created_at） - CI 流程中可用正则检查 SQL 文件：
/CREATE\s+TABLE\s+`?([A-Z_]+)`?/i匹配到大写字母就报错 - 用 Doctrine DBAL 或 Laravel Schema Builder 等抽象层时，也要确认其生成的表名是否受配置影响（多数默认小写）
常见错误现象与排查方式
遇到 “table doesn’t exist” 却确定 SQL 没写错？大概率是大小写惹的祸。
- 错误信息示例：
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'myapp.User' doesn't exist—— 注意单引号里的User是大写 - 登录 MySQL 手动查：
SHOW TABLES LIKE 'user';（小写）和SHOW TABLES LIKE 'User';（大写）结果可能不同 - 确认当前设置：
SELECT @@lower_case_table_names; - Docker 环境特别容易踩坑：宿主机是 macOS，容器内 MySQL 镜像默认
=0，没显式配置就会不一致
真正的难点不在 PHP 怎么写，而在于整个交付链路（开发 → 测试 → CI → 生产）是否共享同一套大小写约定。一旦某环脱离，修复成本远高于初期统一命名。
