系统升级碰到的MySQL问题

系统数据导出后，再使用工具导入备份时出现“MySQL server has gone away”错误，经过搜索发现，这可能是因为其中一些insert语句的大小超出了mysql目前设置的缓冲区大小。

解决办法：
修改my.ini
打开my.ini 找到[mysqld]这一行，下面添加
[mysqld]
#扩大缓冲区，具体数字可以根据自己需要设定
max_allowed_packet=16M 

保存后，重启mysql。

此外，原本的数据库表名均为驼峰式的大小写，但是存入数据库后发现表名全部变为小写，大惑不解。搜索到一篇文章，证实，这是mysql5的一个做法之一。

原文：http://yuweijun.blogspot.com/2008/07/922-mysql5.html

引用

在MySQL中，数据库对应数据目录中的目录。数据库中的每个表至少对应数据库目录中的一个文件(也可能是多个，取决于存储引擎)。因此，所使用操作系统的大小写敏感性决定了数据库名和表名的大小写敏感性。这说明在大多数Unix中数据库名和表名对大小写敏感，而在Windows中对大小写不敏感。一个显著的例外情况是Mac OS X，它基于Unix但使用默认文件系统类型(HFS+)，对大小写不敏感。然而，Mac OS X也支持UFS卷，该卷对大小写敏感，就像Unix一样。

注释：尽管在某些平台中数据库名和表名对大小写不敏感，不应在同一查询中使用不同的大小写来引用给定的数据库或表。下面的查询不会工作，因为它同时引用了表my_tables和as MY_tables：

mysql> SELECT * FROM my_table WHERE MY_TABLE.col=1;
列、索引、存储子程序和触发器名在任何平台上对大小写不敏感，列的别名也不敏感。

默认情况，表别名在Unix中对大小写敏感，但在Windows或Mac OS X中对大小写不敏感。下面的查询在Unix中不会工作，因为它同时引用了别名a和A：

mysql> SELECT col_name FROM tbl_name AS a
-> WHERE a.col_name = 1 OR A.col_name = 2;
然而，该查询在Windows中是可以的。要想避免出现差别，最好采用一致的转换，例如总是用小写创建并引用数据库名和表名。在大多数移植和使用中建议使用该转换。

在MySQL中如何在硬盘上保存和使用表名和数据库名由lower-case-table-names系统变量确定，可以在启动mysqld时设置。lower-case-table-names可以采用下面的任一值：

0:
使用CREATE TABLE或CREATE DATABASE语句指定的大写和小写在硬盘上保存表名和数据库名。名称比较对大小写敏感。在Unix系统中的默认设置即如此。请注意如果在大小写不敏感的文件系统上用--lower-case-table-names=0强制设为0，并且使用不同的大小写访问MyISAM表名，会导致索引破坏。

1:
表名在硬盘上以小写保存，名称比较对大小写敏感。MySQL将所有表名转换为小写以便存储和查找。该行为也适合数据库名和表的别名。该值为Windows和Mac OS X系统中的默认值。

2:
表名和数据库名在硬盘上使用CREATE TABLE或CREATE DATABASE语句指定的大小写进行保存，但MySQL将它们转换为小写以便查找。名称比较对大小写敏感。注释：只在对大小写不敏感的文件系统上适用! InnoDB表名以小写保存，例如lower-case-table-names=1。

在Windows和Mac OS X中，lower-case-table-names的 默认值是1。

我们的系统部署是在linux下的mysql4，而开发环境则是windows下mysql5，这2天做系统的升级，被这2个差异折腾得够呛，这边生成的表全部小写，而linux下则是大小写混杂（它区分大小写），结果导致数据的导入导出异常麻烦，导出的数据库目前虽然只有十几M，但是用文本编辑器手动的修改表名一样还是非常的痛苦，文本编辑器改动表名大小写卡得要死。