遇到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

数据表 collect ( id, title ,info ,vtype) 就这4个字段，其中 title 用定长，info 用text, id 是逐渐，vtype是tinyint，vtype是索引。这是一个基本的新闻系统的简单模型。现在往里面填充数据，填充10万篇新闻。

最后collect 为 10万条记录，数据库表占用硬盘1.6G。OK ,看下面这条sql语句：

select id,title from collect limit 1000,10; 很快；基本上0.01秒就OK，再看下面的

select id,title from collect limit 90000,10; 从9万条开始分页，结果？

8-9秒完成，my god 哪出问题了？？？？其实要优化这条数据，网上找得到答案。看下面一条语句:

select id from collect order by id limit 90000,10; 很快，0.04秒就OK。 为什么？因为用了id主键做索引当然快。网上的改法是：

select id,title from collect where id>=(select id from collect order by id limit 90000,1) limit 10;

这就是用了id做索引的结果。可是问题复杂那么一点点，就完了。看下面的语句

select id from collect where vtype=1 order by id limit 90000,10; 很慢，用了8-9秒！

到了这里我相信很多人会和我一样，有崩溃感觉！vtype 做了索引了啊？怎么会慢呢？vtype做了索引是不错，你直接 select id from collect where vtype=1 limit 1000,10; 是很快的，基本上0.05秒，可是提高90倍，从9万开始，那就是0.05*90=4.5秒的速度了。和测试结果8-9秒到了一个数量级。从这里开始有人 提出了分表的思路，这个和discuz 论坛是一样的思路。思路如下：

建一个索引表： t (id,title,vtype) 并设置成定长，然后做分页，分页出结果再到 collect 里面去找info 。 是否可行呢？实验下就知道了。

10万条记录到 t(id,title,vtype) 里，数据表大小20M左右。用

select id from t where vtype=1 order by id limit 90000,10; 很快了。基本上0.1-0.2秒可以跑完。为什么会这样呢？我猜想是因为collect 数据太多，所以分页要跑很长的路。limit 完全和数据表的大小有关的。其实这样做还是全表扫描，只是因为数据量小，只有10万才快。OK， 来个疯狂的实验，加到100万条，测试性能。

加了10倍的数据，马上t表就到了200多M，而且是定长。还是刚才的查询语句，时间是0.1-0.2秒完成！分表性能没问题？错！因为我们的limit还是9万，所以快。给个大的，90万开始

select id from t where vtype=1 order by id limit 900000,10; 看看结果，时间是1-2秒！

why ?? 分表了时间还是这么长，非常之郁闷！有人说定长会提高limit的性能，开始我也以为，因为一条记录的长度是固定的，mysql 应该可以算出90万的位置才对啊？ 可是我们高估了mysql 的智能，他不是商务数据库，事实证明定长和非定长对limit影响不大？ 怪不得有人说 discuz到了100万条记录就会很慢，我相信这是真的，这个和数据库设计有关！

难道MySQL 无法突破100万的限制吗？？？到了100万的分页就真的到了极限？？？

答案是： NO !!!! 为什么突破不了100万是因为不会设计mysql造成的。下面介绍非分表法，来个疯狂的测试！一张表搞定100万记录，并且10G 数据库，如何快速分页！

好了，我们的测试又回到 collect表，开始测试结论是： 30万数据，用分表法可行，超过30万他的速度会慢道你无法忍受！当然如果用分表+我这种方法，那是绝对完美的。但是用了我这种方法后，不用分表也可以完美解决！

答案就是：复合索引！ 有一次设计mysql索引的时候，无意中发现索引名字可以任取，可以选择几个字段进来，这有什么用呢？开始的select id from collect order by id limit 90000,10; 这么快就是因为走了索引，可是如果加了where 就不走索引了。抱着试试看的想法加了 search(vtype,id) 这样的索引。然后测试

select id from collect where vtype=1 limit 90000,10; 非常快！0.04秒完成！

再测试: select id ,title from collect where vtype=1 limit 90000,10; 非常遗憾，8-9秒，没走search索引！

再测试：search(id,vtype)，还是select id 这个语句，也非常遗憾，0.5秒。

综上：如果对于有where 条件，又想走索引用limit的，必须设计一个索引，将where 放第一位，limit用到的主键放第2位，而且只能select 主键！

完美解决了分页问题了。可以快速返回id就有希望优化limit ， 按这样的逻辑，百万级的limit 应该在0.0x秒就可以分完。看来mysql 语句的优化和索引时非常重要的！

好了，回到原题，如何将上面的研究成功快速应用于开发呢？如果用复合查询，我的轻量级框架就没的用了。分页字符串还得自己写，那多麻烦？这里再看一个例子，思路就出来了：

select * from collect where id in (9000,12,50,7000); 竟然 0秒就可以查完！

mygod ，mysql 的索引竟然对于in语句同样有效！看来网上说in无法用索引是错误的！

有了这个结论，就可以很简单的应用于轻量级框架了：

代码如下：

$db=dblink();
$db->pagesize=20;

$sql=”select id from collect where vtype=$vtype”;

$db->execute($sql);
$strpage=$db->strpage(); //将分页字符串保存在临时变量，方便输出
while($rs=$db->fetch_array()){
$strid.=$rs[‘id’].’,';
}
$strid=substr($strid,0,strlen($strid)-1); //构造出id字符串
$db->pagesize=0; //很关键，在不注销类的情况下，将分页清空，这样只需要用一次数据库连接，不需要再开；
$db->execute(“select id,title,url,sTime,gTime,vtype,tag from collect where id in ($strid)”);

<?php while($rs=$db->fetch_array()): ?>
<tr>
<td>&nbsp;<?php echo $rs[‘id’];?></td>
<td>&nbsp;<?php echo $rs[‘url’];?></td>
<td>&nbsp;<?php echo $rs[‘sTime’];?></td>
<td>&nbsp;<?php echo $rs[‘gTime’];?></td>
<td>&nbsp;<?php echo $rs[‘vtype’];?></td>
<td>&nbsp;<a href=”?act=show&id=<?php echo $rs[‘id’];?>” target=”_blank”><?php echo $rs[‘title’];?></a></td>
<td>&nbsp;<?php echo $rs[‘tag’];?></td>
</tr>
<?php endwhile; ?>
</table>
<?php
echo $strpage;

通过简单的变换，其实思路很简单：1）通过优化索引，找出id，并拼成 “123,90000,12000” 这样的字符串。2）第2次查询找出结果。

小小的索引+一点点的改动就使mysql 可以支持百万甚至千万级的高效分页！

通过这里的例子，我反思了一点：对于大型系统，PHP千万不能用框架，尤其是那种连sql语句都看不到的框架！因为开始对于我的轻量级框架都差点崩 溃！只适合小型应用的快速开发，对于ERP,OA，大型网站，数据层包括逻辑层的东西都不能用框架。如果程序员失去了对sql语句的把控，那项目的风险将 会成几何级数增加！尤其是用mysql 的时候，mysql 一定需要专业的dba 才可以发挥他的最佳性能。一个索引所造成的性能差别可能是上千倍！

PS: 经过实际测试，到了100万的数据，160万数据，15G表，190M索引，就算走索引，limit都得0.49秒。所以分页最好别让别人看到10万条以后的数据， 要不然会很慢！就算用索引。经过这样的优化，mysql到了百万级分页是个极限！但有这样的成绩已经很不错，如果你是用sqlserver肯定卡死！而 160万的数据用 id in (str) 很快，基本还是0秒。如果这样，千万级的数据，mysql应该也很容易应付。

通过搜索发现这个问题是mysql查询创建临时文件时，临时目录的空间不足导致的。

这个错误如果想看到它的现象，就必须在sql运行时来监视这个临时文件夹的大小，就可以看到mysql在/tmp下创建了一个临时文件，这个临时文件的大小取决于sql语句以及表的大小。

解决方法：配置临时文件大小

参考

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