MySQL大小写补坑记

背景:由于项目开始时数据库设计经验不足,数据库名和部分数据表名都含有大写字母。但问题是,Linux上数据库名和表名是区分大小写的,而Windows上是不区分大小写的。结果就是在看本地的数据库的时候,对着写的代码是小写的表名,后来传到服务器上却发现报错,几经审查才发觉是表名的大小写不统一的问题。真是天坑啊,坑了自己也坑了小伙伴。怎么办呢?代码已经比较多了,不太可能一下子就把代码里面的表名都改过来。网上看到说设置 lower_case_table_names 可以使Linux上的数据库表名不区分大小写,那就试试吧。

ACTION1:直接修改服务器上 lower_case_table_names=1并重启 ,结果网站挂掉了,说找不到数据库!而本地通过MySQL-Front连接到服务器,显示有小写的 awzthink,但是点进去却说 "awzthink"数据库不存在 这样的话。第一次尝试失败,只能把配置先改回来,网站继续运行。

分析:这样看来,似乎代码本来用的大写awzThink和远程工具用的全小写awzthink都找不到那个数据库,那就想到直接把数据库名直接改为全小写。但是MySQL并没有提供修改数据库名的功能,所以只能新建数据库以及配置数据库用户,然后把所有数据表复制过去,再修改代码中的数据库配置。因为白天网站有一定流量,于是把这项任务安排是深夜。

ACTION2:是夜月黑风高,在服务器上把数据表复制到新的数据库中去,修改代码中的数据库配置(就只有一行),然后修改数据库自动备份脚本,上传。OK,网站运行正常,数据导出来查看也没有出入。再次尝试设置 lower_case_table_names=1并重启,结果那些有大写字母的表还是查询不出来,只好把此配置改回来。

分析:到这一步,数据库名已经改为小写,虽说对代码优化还是没什么帮助,但想要设置lower_case_table_names还是得必须经过这一步,就是必要不充分条件。对于为什么配置这个选项还是没有把传说中的大小写问题修好,还是要详细了解lower_case_table_names这个参数是做什么用的。

分析:后来百度搜索到ITEYE上的一篇博文,终于大概明白是怎么一回事。简单归纳就是:为0时(Linux默认),大小写敏感,创建和查询都是区分大小写;为1时,创建表以小写,查询表也是以小写;为2时,创建表区分大小写,查询表以小写。这样说的话应该就明白了,在Linux上如果本来是以有大写字母创建的表和数据库,如果后来配置设置为1或2时,那么就无论如何都查询不出来了。这个只对表名和数据库名,字段名是所有系统都区分大小写。所以解决办法是,修改表名为小写,然后设置lower_case_table_names=1并重启

ACTION3:再到凌晨,先截图保存现在的数据库表名,在网站低峰期修改表名为小写,再修改这个配置项,然后重启MySQL。注意修改表名到重启MySQL成功之前这一段时间,代码运行是会报错的。重启MySQL之后,网站就可以正常运行了。而代码中的SQL语句表名比较多而繁杂,可以对着截图以后慢慢改。

END:扫地完毕,小伙伴们可以安心地写MySQL了,不用再烦恼大小写问题了。对于原来代码中的大写表名,等闲一点再批量查找修改吧。

附:修改lower_case_tables_names配置项的方法>>>

1、ROOT用户登录,vi /etc/my.cnf
2、找到 [mysqld],在里面加入一行 lower_case_table_names=1
3、重启数据库 service mysqld restart

时间: 2024-11-05 11:53:03

MySQL大小写补坑记的相关文章

Spark踩坑记——数据库(Hbase+Mysql)转

转自:http://www.cnblogs.com/xlturing/p/spark.html 前言 在使用Spark Streaming的过程中对于计算产生结果的进行持久化时,我们往往需要操作数据库,去统计或者改变一些值.最近一个实时消费者处理任务,在使用spark streaming进行实时的数据流处理时,我需要将计算好的数据更新到hbase和mysql中,所以本文对spark操作hbase和mysql的内容进行总结,并且对自己踩到的一些坑进行记录. Spark Streaming持久化设计

[转]Spark 踩坑记:数据库(Hbase+Mysql)

https://cloud.tencent.com/developer/article/1004820 Spark 踩坑记:数据库(Hbase+Mysql) 前言 在使用Spark Streaming的过程中对于计算产生结果的进行持久化时,我们往往需要操作数据库,去统计或者改变一些值. 最近一个实时消费者处理任务,在使用spark streaming进行实时的数据流处理时,我需要将计算好的数据更新到hbase和mysql中,所以本文对spark操作hbase和mysql的内容进行总结,并且对自己

SQL Labs刷题补坑记录(less1-less30)

补坑加1,这几天快速刷一下sqllabs 来巩固下sql注入基础吧,也算是把很久以前没刷的过一遍,do it! 第一部分: LESS1: 直接报错,有回显的注入, http://localhost/sqli-labs-master/Less-1/?id=1' order by 3--+ 就可以确定字段然后使用union查询即可 http://localhost/sqli-labs-master/Less-1/?id=-1' union select 1,2,3--+ 接下来就是常规的查库: ht

【转】Vue 脱坑记 - 查漏补缺(汇总下群里高频询问的xxx及给出不靠谱的解决方案)

前言 文章内容覆盖范围,芝麻绿豆的破问题都有,不止于vue; 给出的是方案,但不是手把手一字一句的给你说十万个为什么! 有三类人不适合此篇文章: "喜欢站在道德制高点的圣母婊" – 适合去教堂 "无理取闹的键盘侠" – 国际新闻版块欢迎你去 "有一定基础但又喜欢逼逼的人" 得得得,老子知道你厉害了,你好牛逼,这些问题那么简单,都是小白看的 这种傻瓜文,简直浪费老子的时间! 对于以上三类人,走吧,这里不是你来装逼的地方. 你们也不值得看老子花那么多

<<Python编程:从入门到实践>>踩坑记 Django

<<Python编程:从入门到实践>>踩坑记 Django Django Python 19.1.1.5 模板new_topic 做完书上的步骤后,对主题添加页面经行测试,但是浏览器显示 服务器异常. 个人采用的开发环境是virtual studio code , 测试起来很是难受,因为我配置的debug环境,断点操作没有作用. 经过我不断的测试,才发现我失败的原因是由于之前的误操作,先建立new_pizzas.py后改为new_pizzas.html的,错误就在这里.在我之后新建

.NET Core爬坑记 1.0 项目文件

前言: 之所以要写这个系列是因为在移植项目到ASP.NET Core平台的过程中,遇到了一些“新变化”,这些变化有编译方面的.有API方面的,今天要讲的是编译方面的一些问题.我把它们整理后分享出来,以便各位博友不要再遇到这些坑. 在Dotnet Core RC2版本中,project.json 管理着整个项目,包括编译文件.依赖包管理.版本信息.平台依赖与发布等功能. 关于项目中引用: 比如我们一般看到Project.json中一般会有如下内容: "dependencies": { &

UiAutomator2.0升级填坑记

UiAutomator2.0升级填坑记 SkySeraph May. 28th 2017 Email:[email protected] 更多精彩请直接访问SkySeraph个人站点:www.skyseraph.com 啰嗦 Google Android Developers 在2015年3月就发布了UiAutomator 2.0版本(下文简称U2),而公司的核心产品中用到还是UiAutomator老版本(下文简称U1),业界用U2的也不是很多,虽然有诸多问题和不便(如高版本OS中不支持Remo

iptables踩坑记

1:第一坑:众所周知nf_conntrack,下面会有介绍补坑方法. 2:连环坑: 要解决第一个坑,需要修改内核参数,如: net.netfilter.nf_conntrack_tcp_timeout_established = 600 net.netfilter.nf_conntrack_max = 1048576 net.nf_conntrack_max = 1048576 这几个参数是基于nf_conntrack模块的,如果nf_conntrack在系统中没有被加载,则上面三个选项就恢复成

踩坑记:httpComponents 的 EntityUtils

今天写的一个服务程序,有人报告获得的数据中文乱码,而我是用 apache 通过 httpComponents 去取得数据的,于是开启日志的 debug 级别. 在日志里果然发现中文不见了,有乱码出现: 2014-07-02 16:35:01.348 DEBUG [Wire.java:86] http-outgoing-8 << "<?xml version="1.0" encoding="UTF-8"?>... subject=&q