IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

MySql lower_case_table_names迷思

iMySQL 2015-12-26 20:34:04 累计浏览 1,296 次
本机暂存

导读

关于 lower_case_table_names 选项的设置的建议是怎样的呢?

问题由来

我个人认为,纠结于这个选项设置源于有些项目是从ORACLE或SQL Server迁移过来,在这两个数据库系统中,都无需关心数据表的大小写。而在MySQL中,默认是要区分大小写的(因为Unix/Linux文件系统是区分文件名大小写的),除非在windows系统下(windows系统是不区分大小写的)。

老叶的建议

我在公司制定的规范是要求默认设置 lower_case_table_names=0 的,也就是区分大小写。那么问题来了,如果是从ORACLE或SQL Server迁移到MYSQL的应用应该怎么处理呢?

我的建议是:

  • 首先,检查确认在应用程序中(或者抓取一段时间的请求日志),数据表名的写法是大写、小写还是混用,如果都是大写或者都是小写,那就更简单些了;

  • 其次,根据上面检查的结果,确定迁移到MySQL后统一使用大写还是小写(使用哪种规则的改动代价更小);

  • 最后,利用Linux下的awk\sed等工具,将包含数据表关键字的地方全部替换成第二部定义好的表名方案;

这样一来,就可以完成数据表名方案的切换了。

当然了,肯定有人(比如某领导、某PM,你懂得的,O(∩_∩)O哈哈~)会说全部修改表名风险太大,需要全面测试,这个项目时间进度很紧张,希望能先上线。这种情况就没办法了,只能闲设置 lower_case_table_names=1,然后迁移数据,优先保证项目进度。

but,即便这时候,我们也建议数据表初始化时,统一采用大写或小写的表名,在项目的后续过程中,通过开启general log的方式,把所有请求SQL中使用的表名都记录下来,然后检查还有哪些和我们定义的规则不一样,再逐渐完善修改,最终达到最终目标。

写在最后

强烈建议在定义数据库设计规范时,统一采用全部都大写或全部都小写的数据表命名规则,没必要为了所谓的美观,弄出一堆大小写混合的表名,是在太操蛋了。

同分类推荐文章

  1. 第七章 事务 (2026-04-07 08:00:00)
  2. 第六章:分区 (2026-03-29 08:00:00)
  3. Neko Master: 从 0 到 1K+ Star 的 Vibe Coding 实践 (2026-03-01 08:00:00)

查看更多 数据库 文章 →

建议继续学习

  1. 用Hyer来进行网站的抓取 (累计阅读 158,183)
  2. MySQL数据库在实际应用一些方面的介绍 (累计阅读 36,341)
  3. WordPress插件开发 -- 在插件使用数据库存储数据 (累计阅读 29,100)
  4. Mysql监控指南 (累计阅读 21,242)
  5. 由浅入深探究mysql索引结构原理、性能分析与优化 (累计阅读 16,245)
  6. 在Apache2.2.XX下安装Mod-myvhost模块 (累计阅读 12,999)
  7. 15个最好的免费开源电子商务平台 (累计阅读 12,475)
  8. 浅谈MySQL索引背后的数据结构及算法 (累计阅读 11,591)
  9. 整理了一份招PHP高级工程师的面试题 (累计阅读 11,515)
  10. 深入浅出INNODB MVCC机制与原理 (累计阅读 9,634)