IT博客汇
  • 首页
  • 精华
  • 技术
  • 设计
  • 资讯
  • 扯淡
  • 权利声明
  • 登录 注册

    lower_case_table_names迷思

    OurMySQL发表于 2015-12-26 20:33:45
    love 0

    导读

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

    写在最后

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

    抱歉猜想失败,您看看下面的文章有用吗?

    • 2009 年 8 月 20 日 -- 64位Linux上安装Memcached详细步骤
    • 2012 年 12 月 17 日 -- php5.3.8中编译pdo_mysql的艰难历程
    • 2013 年 9 月 2 日 -- mysql sql优化之straight_join
    • 2010 年 8 月 4 日 -- InnoDB主键设计
    • 2010 年 9 月 29 日 -- MySQL锁机制/管理(并发锁,行锁,表锁,预加锁,全局锁等等)
    • 2009 年 4 月 16 日 -- 使用Amanda ZRM备份远程MySQL数据库
    • 2008 年 10 月 9 日 -- MySQL字符串比较函数学习(二) — 比较函数
    • 2012 年 12 月 25 日 -- MySQL源码:JOIN顺序选择的复杂度
    • 2015 年 7 月 21 日 -- MySQL的内存使用
    • 2009 年 2 月 23 日 -- 改良版本mysqldump来备份MYSQL数据库


沪ICP备19023445号-2号
友情链接