遇到The user specified as a definer (‘root’@’%’) does not exist 问题，原因是没有权限，解决方法如下：
1、添加访问权限

执行SQL：grant all privileges on *.* to root@”%” identified by “.”;

2、更新权限
执行SQL： flush privileges;

问题解决。

MySQL57服务无法启动

查看了官方文档：

Use lower_case_table_names=1 on all systems. The main disadvantage with this is that when you use SHOW TABLES or SHOW DATABASES, you do not see the names in their original lettercase.

Use lower_case_table_names=0 on Unix and lower_case_table_names=2 on Windows. This preserves the lettercase of database and table names. The disadvantage of this is that you must ensure that your statements always refer to your database and table names with the correct lettercase on Windows. If you transfer your statements to Unix, where lettercase is significant, they do not work if the lettercase is incorrect.

在Windows下配置 lower_case_table_names=2。

然而，该查询在Windows中是可以的。要想避免出现差别，最好采用一致的转换，例如总是用小写创建并引用数据库名和表名。在大多数移植和使用中建议使用该转换。
在MySQL中如何在硬盘上保存和使用表名和数据库名由lower_case_tables_name系统变量确定，可以在启动mysqld 时设置。lower_case_tables_name可以采用下面的任一值：

http://blog.chinaunix.net/uid-26602509-id-4104999.html

1、InnoDB存储引擎
InnoDB是MySQL的默认事务型引擎，它被设计用来处理大量的短期(short-lived)事务。除非有非常特别的原因需要使用其他的存储引擎，否则应该优先考虑InnoDB引擎。

建议使用MySQL5.5及以后的版本，因为这个版本及以后的版本的InnoDB引擎性能更好。
MySQL4.1以后的版本中，InnoDB可以将每个表的数据和索引存放在单独的文件中。这样在复制备份崩溃恢复等操作中有明显优势。可以通过在my.cnf中增加innodb_file_per_table来开启这个功能。如下：

[mysqld]
innodb_file_per_table

InnoDB采用MVCC来支持高并发，并且实现了四个标准的隔离级别。其默认级别是REPEATABLE READ(可重复读)，并且通过间隙锁(next-key locking)策略防止幻读的出现。(事务和事务隔离级别是另一个大题目，各自网补吧)。

InnoDB是基于聚簇索引建立的，聚簇索引对主键查询有很高的性能。不过它的二级索引(secondary index，非主键索引)中必须包含主键列，所以如果主键列很大的话，其他的所有索引都会很大。因此表上的索引较多的话，主键应当尽可能的小。

InnoDB的存储格式是平台独立的，可以将数据和索引文件从Intel平台复制到Sun SPARC平台或其他平台。

InnoDB通过一些机制和工具支持真正的热备份，MySQL的其他存储引擎不支持热备份。

2、MyISAM存储引擎
MyISAM提供了大量的特性，包括全文索引、压缩、空间函数(GIS)等，但MyISAM不支持事务和行级锁，有一个毫无疑问的缺陷就是崩溃后无法安全恢复。

MyISAM会将表存储在两个文件在中：数据文件和索引文件，分别是.MYD和.MYI为扩展名。
在MySQL5.0以前，只能处理4G的数据，5.0中可以处理256T的数据。

在数据不再进行修改操作时，可以对MyISAM表进行压缩，压缩后可以提高读能力，原因是减少了磁盘I/O。

3、Archive引擎
Archive存储引擎只支持INSERT和SELECT操作，在MySQL5.1之前不支持索引。
Archive表适合日志和数据采集类应用。
Archive引擎支持行级锁和专用的缓存区，所以可以实现高并发的插入，但它不是一个事物型的引擎，而是一个针对高速插入和压缩做了优化的简单引擎。

4、Blackhole引擎
Blackhole引擎没有实现任何存储机制，它会丢弃所有插入的数据，不做任何保存。但服务器会记录Blackhole表的日志，所以可以用于复制数据到备库，或者简单地记录到日志。但这种应用方式会碰到很多问题，因此并不推荐。

5、CSV引擎
CSV引擎可以将普通的SCV文件作为MySQL的表来处理，但不支持索引。
CSV引擎可以作为一种数据交换的机制，非常有用。

6、Federated引擎
Federated引擎是访问其他MySQL服务器的一个代理，尽管该引擎看起来提供了一种很好的跨服务器的灵活性，但也经常带来问题，因此默认是禁用的。

7、Memory引擎
如果需要快速地访问数据，并且这些数据不会被修改，重启以后丢失也没有关系，那么使用Memory表是非常有用。Memory表至少比MyISAM表要快一个数量级。
Memory表是表级锁，因此并发写入的性能较低。它不支持BLOB或TEXT类型的列，并且每行的长度是固定的，这可能呆滞部分内存的浪费。
临时表和Memory表不是一回事。临时表是指使用CREATE TEMPORARY TABLE语句创建的表，它可以使用任何存储引擎，只在单个连接中可见，当连接断开时，临时表也将不复存在。

8、NDB集群引擎
MySQL服务器、NDB集群存储引擎，以及分布式的、share-nothing的、容灾的、高可用的NDB数据库的组合，被称为MySQL集群(MySQL Cluster)。

其他第三方或社区引擎
XtraDB：是InnoDB的一个改进版本，可以作为InnoDB的一个完美的替代产品。
TokuDB：使用了一种新的叫做分形树(Fractal Trees)的索引数据结构。
Infobright：是最有名的面向列的存储引擎。
Groonga：是一款全文索引引擎。
OQGraph：该引擎由Open Query研发，支持图操作(比如查找两点之间的最短路径)。
Q4M：该引擎在MySQL内部实现了队列操作。
SphinxSE：该引擎为Sphinx全文索引搜索服务器提供了SQL接口。

二、选择合适的引擎
大部分情况下，InnoDB都是正确的选择，可以简单地归纳为一句话“除非需要用到某些InnoDB不具备的特性，并且没有其他办法可以替代，否则都应该优先选择InnoDB引擎”。
除非万不得已，否则建议不要混合使用多种存储引擎，否则可能带来一系列负责的问题，以及一些潜在的bug和边界问题。

如果应用需要不同的存储引擎，请先考虑以下几个因素：

事务：
如果应用需要事务支持，那么InnoDB(或者XtraDB)是目前最稳定并且经过验证的选择。

备份：
如果可以定期地关闭服务器来执行备份，那么备份的因素可以忽略。反之，如果需要在线热备份，那么选择InnoDB就是基本的要求。

崩溃恢复
MyISAM崩溃后发生损坏的概率比InnoDB要高很多，而且恢复速度也要慢。

特有的特性
如果一个存储引擎拥有一些关键的特性，同时却又缺乏一些必要的特性，那么有时候不得不做折中的考虑，或者在架构设计上做一些取舍。

有些查询SQL在不同的引擎上表现不同。比较典型的是：
SELECT COUNT(*) FROM table;
对于MyISAM确实会很快，但其他的可能都不行。

三、应用举例

1、日志型应用
MyISAM或者Archive存储引擎对这类应用比较合适，因为他们开销低，而且插入速度非常快。
如果需要对记录的日志做分析报表，生成报表的SQL很可能会导致插入效率明显降低，这时候该怎么办？
一种解决方法，是利用MySQL内置的复制方案将数据复制一份到备库，然后在备库上执行比较消耗时间和CPU的查询。当然也可以在系统负载较低的时候执行报表查询操作，但应用在不断变化，如果依赖这个策略可能以后会导致问题。
另一种方法，在日志记录表的名字中包含年和月的信息，这样可以在已经没有插入操作的历史表上做频繁的查询操作，而不会干扰到最新的当前表上的插入操作。

2、只读或者大部分情况下只读的表
有些表的数据用于编制类目或者分列清单（如工作岗位），这种应用场景是典型的读多写少的业务。如果不介意MyISAM的崩溃恢复问题，选用MyISAM引擎是合适的。（MyISAM只将数据写到内存中，然后等待操作系统定期将数据刷出到磁盘上）

3、订单处理
涉及订单处理，支持事务是必要的，InnoDB是订单处理类应用的最佳选择。

4、大数据量
如果数据增长到10TB以上的级别，可能需要建立数据仓库。Infobright是MySQL数据仓库最成功的方案。也有一些大数据库不适合Infobright，却可能适合TokuDB。

http://toplchx.iteye.com/blog/1941415

解决办法：
检查SQL文件查看当前编码，将编码改为：以utf8无bom格式编码。

以下来源网络，请参考：

UTF-8 不需要 BOM，尽管 Unicode 标准允许在 UTF-8 中使用 BOM。
所以不含 BOM 的 UTF-8 才是标准形式，在 UTF-8 文件中放置 BOM 主要是微软的习惯（顺便提一下：把带有 BOM 的小端序 UTF-16 称作「Unicode」而又不详细说明，这也是微软的习惯）。

BOM（byte order mark）是为 UTF-16 和 UTF-32 准备的，用于标记字节序（byte order）。微软在 UTF-8 中使用 BOM 是因为这样可以把 UTF-8 和 ASCII 等编码明确区分开，但这样的文件在 Windows 之外的操作系统里会带来问题。

「UTF-8」和「带 BOM 的 UTF-8」的区别就是有没有 BOM。即文件开头有没有 U+FEFF。
UTF-8 的网页代码不应使用 BOM，否则常常会出错。

那为什么同一个问题会出现不同的提示呢？

测试结果是这样的：
1、如果这个时候数据表里面没有数据，而且我们用使用 INSERT INTO VALUES 这样的语句插入，就会提示 Duplicate entry ‘xxx’ for key ‘PRIMARY’ 这类的字样。

2、如果这个时候数据表里面没有数据，而且我们使用 INSERTINTO SELECT FROM 这样的语句插入，并且存储引擎是INNODB的话，就会提示 Failed to read auto-increment value from storage engine 这样的错误.

3、如果这个时候数据表里面有数据，则总是会出现Duplicate entry ‘xxx’ for key ‘PRIMARY’ 这类的字样的错误。
所以，出现Duplicate entry ‘xxx’ for key ‘PRIMARY’ 这个时容易理解的。而另外一个提示是因为INNODB 引擎特有的二级缓存所导致的。数据不会先插入数据表，而会先存到缓存里面，只是增加表里的自增数。所以当自增数达到极限时，InnoDB要获取自增值然后存储到缓存的时候，发现找不到更高的数字了。

http://blog.csdn.net/topasstem8/article/details/17893197

MySQL5.0 Bug, 要把联合的表用括号包含起来才行:

SELECT (c.id, a.id, b.id) FROM A a, B b LEFT JOIN C c ON c.a_id = a.a_id AND c.b_id = b.b_id

这句话执行应该是没有错误的,但是Mysql 5 下执行则会出错。

因为mysql下有这样一个BUG,要把联合的表用括号包含起来才行：

SELECT (c.id, a.id, b.id) FROM (A a, B b) LEFT JOIN C c ON c.a_id = a.a_id AND c.b_id = b.b_id

以前没有遇到过，于是查找资料解决这个问题。得知是由于内存表的大小超过了规定的范围，于是搜索解决方法，网上提到的有两种解决方法，

一种是修改 my-innodb-heavy-4G.ini文件里的tmp_table_size参数，然后重启mysql服务。

另外一种是修改max_heap_table_size参数。

[root@localhost etc]# vi /etc/rc.d/init.d/mysql
找到
$bindir/mysqld_safe –datadir=$datadir –pid-file=$pid_file >/dev/null 2>&1 &
修改为
$bindir/mysqld_safe –datadir=$datadir –pid-file=$pid_file -O tmp_table_size=64M -O max_heap_table_size=32M >/dev/null 2>&1 &

重启mysql
[root@localhost etc]# /usr/bin/mysqladmin -u root -p shutdown
Enter password:
[root@localhost etc]# /etc/init.d/mysql start
[root@localhost etc]# mysql

查看是否己修改
mysql> show variables like ‘%max_heap_table_size%';
+———————+———-+
| Variable_name | Value |
+———————+———-+
| max_heap_table_size | 33553408 |
+———————+———-+
1 row in set (0.00 sec)
mysql> show variables like ‘%tmp_table_size%';
+—————-+———-+
| Variable_name | Value |
+—————-+———-+
| tmp_table_size | 67108864 |
+—————-+———-+
1 row in set (0.00 sec)
己经修改成功！

http://blog.sina.com.cn/s/blog_8e743a770101iwzt.html

当mysql的临时文件大小设置太小，或者由于并发量太大导致临时文件存放的目录空间大小不够时都会报这个错误。”incorrect key file for the table ‘/tmp/#sql….';try to repair it”

一般的tmp目录的权限比较特别是drwxrwxrwt 就是1777
表示任何人都可以在此目录拥有写权限但是不能删除别人拥有的文件。

d:指的是目录
t:sticky bit，设置了粘住位

具体修改临时表目录的步骤为：

1) 查看法语站当前磁盘空间使用情况，建议将临时表存放目录设置在/var下。

【修改tmp目录】Incorrect <wbr>key <wbr>file <wbr>for <wbr>table <wbr>’/tmp/#sql_bd2_0.MYI’解决
[root@wholesale /]# mkdir /var/tmp
[root@wholesale /]# chmod 1777 /var/tmp/
2) my.cnf中[mysqld]下增加：

tmpdir=/var/tmp

3) 重启mysql服务
4) 查看mysql错误日志情况，看是否报错。
5) 进入mysql查看当前的tmpdir情况，确认是否修改完成
show variables like ‘tmpdir';

http://blog.sina.com.cn/s/blog_4c197d420101bdn9.html

一般的情况下，我们的分页SQL语句是这样的：

SELECT * FROM table ORDER BY id LIMIT 1000,10;
以上SQL语句在原理上和在实际操作中是不会存在什么问题，但是当table表的数据量达到几十万以上的时候，上面的语句执行一遍，可能会要执行个十几秒的时间，并且当页数越靠后的话，执行的时间会越长，这个时候我们就需要找到一种更快的查询办法来替代这种操作了。

网上已经有很多优化的方法，基本都是这样的：

SELECT * FROM table WHERE id >= (SELECT id FROM table LIMIT 1000000, 1) LIMIT 10;
以上SQL语句是一个不错的解决方法，分页查询的速度基本会保持在1秒之内，但据经验总结得出还有一种更好的办法，如下：

SELECT * FROM table WHERE id BETWEEN 1000000 AND 1000010;
相比以上的解决办法，在速度上还会快了不少。

另外分享两个关于查询的技巧：

（1）如果需要查询 id 不是连续的一段，最佳的做法就是先找出 id ，然后用 in 查询：

SELECT * FROM table WHERE id IN(10000, 100000, 1000000…);
（2）当查询字段一较长字符串的时候，表设计时要为该字段多加一个字段，如存储网址的字段，在需要查询该字段的时候，不要直接查询字符串，效率低下，应该查诡该字串的crc32或md5值。