FAQ系列 | lower_case_table_names迷思

简介: FAQ系列 | lower_case_table_names迷思

导读

关于 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中使用的表名都记录下来,然后检查还有哪些和我们定义的规则不一样,再逐渐完善修改,最终达到最终目标。

写在最后

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

            </div>
相关文章
|
消息中间件 运维 Java
RocketMQ的常规运维实践应用
RocketMQ的常规运维实践应用
|
SQL 运维 关系型数据库
记一次 MySQL 主从同步异常的排查记录,百转千回!
这篇文章主要讲述了在 MySQL 主从同步过程中遇到的一个问题,即从库的 SQL 线程因 Relay Log 损坏导致同步停止。作者首先介绍了现象,从库的 Slave_IO_Running 正常,但 Slave_SQL_Running 停止,报错信息提示可能是 binlog 或 relay log 文件损坏。
581 7
|
存储 关系型数据库 MySQL
lower_case_table_names 修改为何不生效
lower_case_table_names 是 MySQL 和 MariaDB 中的一个系统变量,它决定了数据库和表名在存储和引用时的大小写敏感性。这个变量有以下几个可能的值: 0:表名存储为给定的大小写,并区分大小写。这是大多数 Unix 系统的默认设置。 1:表名在存储和引用时都转换为小写,不区分大小写。这是 Windows 和 macOS 的默认设置。 2:表名存储为给定的大小写,但引用时不区分大小写。 如果你尝试修改 lower_case_table_names 的值但发现它不生效,可能是由以下几个原因造成的: 配置文件位置不正确:确保你在正确的配置文件中进行了修改。对于 MyS
1857 2
|
安全 Linux
学一个Linux命令-pstree
学一个Linux命令-pstree
|
消息中间件 存储 缓存
RocketMQ NameServer
前面我们已经简单地介绍了 RocketMQ 的整体设计思路,本文着重其中 NameServer 部分的实现细节。
RocketMQ NameServer
|
监控 安全 算法
黑客与宕机
造成系统异常宕机(无响应、异常重启)的原因有很多种,最常见的是操作系统内部缺陷和设备驱动缺陷。本文作者将和大家分享内存转储分析的底层逻辑和方法论,并通过一个线上真实案例来展示从分析到得出结论的整个过程,希望对同学们处理此类问题和对系统的理解上有所帮助。
1542 0
黑客与宕机