mysql distance_MySql中的一些小坑

1. mysql启动时，若使用mysqld_safe的方式启动服务，需要使用mysqladmin shutdown的方式来停止服务。

若使用mysqld shutdown的方式停止服务，有可能会出现如下报错：

InnoDB: Unable to lock ./ibdata1, error: 11

InnoDB: Check that you do not already have another

mysqld process

原因推测为：mysqld_safe启动mysql服务之后，mysqld_safe自身也占用着mysqld的进程，导致无法单纯使用mysqld进行服务的关闭。

2. mysql安装结束后，因为linux中的mysql，对表名是默认区分大小写的，应当尽快在my.cnf文件的[mysqld]下，添加“lower_case_table_names=1”

此语句的作用，在广泛意义上，可以理解为：对表名不区分大小写

但准确理解应当为：对输入语句中的表名，先将表名强制转为小写，再执行语句。

3. 若使用 DROP SCHEMA schema_name或 DROP DATABASE database_name欲删除数据库时报以下错误：

ERROR 1010 (HY000): Error dropping database (can’t rmdir ‘.\[schema_name/database_name]’, errno: 17)

可能为：

1. 数据库文件目录中的文件包含人为添加的文件

2. mysql的清理动作没有将数据库文件目录中的数据对象文件完全清理。

上述两种情况，均属于执行rmdir之前，对应的目录没有清空。

上述所说的数据库文件目录，是指：my.cnf文件中的datadir目录下，DROP SCHEMA或DROP DATABASE语句中的schema_name或database_name对应的目录名称。

如：my.cnf文件中，datadir 为“/var/lib/mysql”，报错是在执行“DROP SCHEMA hap_dev”发生，则 数据库文件目录为“/var/lib/mysql”，此目录正常情况下应当只包含在mysql中创建的数据对象的文件，如：创建了表“sys_lang_b”之后，此目录就会产生sys_lang_b对应的数据对象文件。

结合今天的经历，描述一下上述的2和3：

A. 首先，在没有配置“lower_case_table_names=1”的情况下，启动数据库并且使用脚本批量创建了数据对象，语句中的表名均为大写。schema名为“hap_dev”

B. 然后，发现进行查询时，只有使用表名大写才能查询到相应的表，以sys_lang_b为例：

“select * from sys_lang_b”查询失败

“select * from SYS_LANG_B”查询成功

C. 配置“lower_case_table_names=1”并重启mysql服务

D. 此时会发现，无论使用“select * from sys_lang_b”还是 “select * from SYS_LANG_B”都无法查找到sys_lang_b这张表，因为：

在一开始批量创建数据对象时，sys_lang_b就是以大写的“SYS_LANG_B”存入数据库的，而配置了“lower_case_table_names=1”之后，输入的语句中的表名，无论大小写都会先转为小写再去执行，即最终执行的语句都是“select * from sys_lang_b”，导致无法查询到“SYS_LANG_B”。

E. OK现在需要清理整个数据库然后再使用脚本重新批量创建对象。收回schema(hap_dev)所涉及的用户的所有权限，并将用户删除，然后执行“drop schema hap_dev”。

执行“drop schema hap_dev”时报错：ERROR 1010 (HY000): Error dropping database (can’t rmdir ‘./hap_dev’, errno: 17)

F. 在网上查阅发现，大多数情况为：在datadir/schema_name(笔者相应的目录为：/var/lib/mysql/hap_dev)目录下，存在人为产生的非数据库对象文件，导致mysql执行rmdir时，因对应的目录不为空而报错。

而linux中rmdir的语法，的确要求其对应的目标目录需要为空目录

在上述事实下，我们可以这样推断，mysql执行drop schema时，会先清理数据对象，因此datadir/schema_name下的数据对象文件会先被清空，若清空数据对象文件后，datadir/schema_name目录下仍存在文件，则rmdir报错。

G. 现在来看看我的情况，在我的/var/lib/mysql/hap_dev目录下，均为之前批量创建的“SYS_LANG_B”等数据对象，不存在任何人为放进入的文件。同时，我也通过放开这个目录的所有权限排除了rmdir的权限问题。

也就是说，如果/var/lib/mysql/hap_dev最后不为空，则里面残留的很可能是数据对象，比如“SYS_LANG_B”等数据表。

是的！大写的“SYS_LANG_B”！

现在mysql中的配置是“lower_case_table_names=1”，在它进行“drop schema hap_dev”时，清理数据对象的阶段中，是否所有输入的表名全部转为小写了，导致“SYS_LANG_B”这些大写表名的数据表都不会被清空，/var/lib/mysql/hap_dev最终残留着这些数据对象文件，最终导致rmdir失败。

H. 是的，最终的解决方法的确奏效了：

取消配置“lower_case_table_names=1”后重启mysql服务，执行drop schema hap_dev成功。

接着再添加配置“lower_case_table_names=1”并重启mysql。执行批量创建数据对象的脚本之后，可正常查询。事实上，我们还会发现，此时数据库中的表名，实际上均为小写。