• 1. 显式的定义一个 INT 类型自增字段的主键，这个字段可以仅用于做主键，不做其他用途
• 2. 如果不显式定义主键的话，可能会导致InnoDB每次都需要对新数据行进行排序，严重损害性能
• 3. 尽量保证不对主键字段进行更新修改，防止主键字段发生变化，引发数据存储碎片，降低IO性能
• 4. 如果需要对主键字段进行更新，请将该字段转变成一个唯一索引约束字段，另外创建一个没有其他业务意义的自增字段做主键
• 5. 主键字段类型尽可能小，能用SMALLINT就不用INT，能用INT就不用BIGINT
• 6. 主键字段放在数据表的第一顺序

相关文章

• 2010-04-13 -- InnoDB Double write
• 2010-03-09 -- Innodb 表和索引结构
• 2010-03-09 -- InnoDB线程并发检查机制
• 2009-12-20 -- Innodb如何使用内存
• 2009-12-20 -- Innodb文件表空间结构
• 2009-12-12 -- InnoDB的”替代品”：Percona XtraDB
• 2009-09-25 -- Innodb表空间page size的选择
• 2009-09-03 -- MySQL InnoDB性能调整的一点实践
• 2009-08-18 -- 随机主键对InnoDB插入性能的影响
• 2009-08-18 -- InnoDB之Dirty Page、Redo log

顾名思义，MySQL Query Cache 就是用来缓存和 Query 相关的数据的。具体来说，Query Cache 缓存了我们客户端提交给 MySQL 的 SELECT 语句以及该语句的结果集。大概来讲，就是将 SELECT 语句和语句的结果做了一个 HASH 映射关系然后保存在一定的内存区域中。

在大部分的 MySQL 分发版本中，Query Cache 功能默认都是打开的，我们可以通过调整 MySQL Server 的参数选项打开该功能。主要由以下5个参数构成：

• query_cache_limit：允许 Cache 的单条 Query 结果集的最大容量，默认是1MB，超过此参数设置的 Query 结果集将不会被 Cache
• query_cache_min_res_unit：设置 Query Cache 中每次分配内存的最小空间大小，也就是每个 Query 的 Cache 最小占用的内存空间大小
• query_cache_size：设置 Query Cache 所使用的内存大小，默认值为0，大小必须是1024的整数倍，如果不是整数倍，MySQL 会自动调整降低最小量以达到1024的倍数
• query_cache_type：控制 Query Cache 功能的开关，可以设置为0(OFF),1(ON)和2(DEMAND)三种，意义分别如下：
  • 0(OFF)：关闭 Query Cache 功能，任何情况下都不会使用 Query Cache
  • 1(ON)：开启 Query Cache 功能，但是当 SELECT 语句中使用的 SQL_NO_CACHE 提示后，将不使用Query Cache
  • 2(DEMAND)：开启 Query Cache 功能，但是只有当 SELECT 语句中使用了 SQL_CACHE 提示后，才使用 Query Cache
• query_cache_wlock_invalidate：控制当有写锁定发生在表上的时刻是否先失效该表相关的 Query Cache，如果设置为 1(TRUE)，则在写锁定的同时将失效该表相关的所有 Query Cache，如果设置为0(FALSE)则在锁定时刻仍然允许读取该表相关的 Query Cache。

Query Cache 如何处理子查询的？
这是我遇到的最为常见的一个问题。其实 Query Cache 是以客户端请求提交的 Query 为对象来处理的，只要客户端请求的是一个 Query，无论这个 Query 是一个简单的单表查询还是多表 Join，亦或者是带有子查询的复杂 SQL，都被当作成一个 Query，不会被分拆成多个 Query 来进行 Cache。所以，存在子查询的复杂 Query 也只会产生一个Cache对象，子查询不会产生单独的Cache内容。UNION[ALL] 类型的语句也同样如此。

Query Cache 是以 block 的方式存储的数据块吗？
不是，Query Cache 中缓存的内容仅仅只包含该 Query 所需要的结果数据，是结果集。当然，并不仅仅只是结果数据，还包含与该结果相关的其他信息，比如产生该 Cache 的客户端连接的字符集，数据的字符集，客户端连接的 Default Database等。

Query Cache 为什么效率会非常高，即使所有数据都可以 Cache 进内存的情况下，有些时候也不如使用 Query Cache 的效率高？
Query Cache 的查找，是在 MySQL 接受到客户端请求后在对 Query 进行权限验证之后，SQL 解析之前。也就是说，当 MySQL 接受到客户端的SQL后，仅仅只需要对其进行相应的权限验证后就会通过 Query Cache 来查找结果，甚至都不需要经过 Optimizer 模块进行执行计划的分析优化，更不许要发生任何存储引擎的交互，减少了大量的磁盘 IO 和 CPU 运算，所以效率非常高。

客户端提交的 SQL 语句大小写对 Query Cache 有影响吗？
有，由于 Query Cache 在内存中是以 HASH 结构来进行映射，HASH 算法基础就是组成 SQL 语句的字符，所以必须要整个 SQL 语句在字符级别完全一致，才能在 Query Cache 中命中，即使多一个空格也不行。

一个 SQL 语句在 Query Cache 中的内容，在什么情况下会失效？
为了保证 Query Cache 中的内容与是实际数据绝对一致，当表中的数据有任何变化，包括新增，修改，删除等，都会使所有引用到该表的 SQL 的 Query Cache 失效。

为什么我的系统在开启了 Query Cache 之后整体性能反而下降了？
当开启了 Query Cache 之后，尤其是当我们的 query_cache_type 参数设置为 1 以后，MySQL 会对每个 SELECT 语句都进行 Query Cache 查找，查找操作虽然比较简单，但仍然也是要消耗一些 CPU 运算资源的。而由于 Query Cache 的失效机制的特性，可能由于表上的数据变化比较频繁，大量的 Query Cache 频繁的被失效，所以 Query Cache 的命中率就可能比较低下。所以有些场景下，Query Cache 不仅不能提高效率，反而可能造成负面影响。

如何确认一个系统的 Query Cache 的运行是否健康，命中率如何，设置量是否足够？
MySQL 提供了一系列的 Global Status 来记录 Query Cache 的当前状态，具体如下：

• Qcache_free_blocks：目前还处于空闲状态的 Query Cache 中内存 Block 数目
• Qcache_free_memory：目前还处于空闲状态的 Query Cache 内存总量
• Qcache_hits：Query Cache 命中次数
• Qcache_inserts：向 Query Cache 中插入新的 Query Cache 的次数，也就是没有命中的次数
• Qcache_lowmem_prunes：当 Query Cache 内存容量不够，需要从中删除老的 Query Cache 以给新的 Cache 对象使用的次数
• Qcache_not_cached：没有被 Cache 的 SQL 数，包括无法被 Cache 的 SQL 以及由于 query_cache_type 设置的不会被 Cache 的 SQL
• Qcache_queries_in_cache：目前在 Query Cache 中的 SQL 数量
• Qcache_total_blocks：Query Cache 中总的 Block 数量

可以根据这几个状态计算出 Cache 命中率，计算出 Query Cache 大小设置是否足够，总的来说，我个人不建议将 Query Cache 的大小设置超过256MB，这也是业界比较常用的做法。

MySQL Cluster 是否可以使用 Query Cache？
其实在我们的生产环境中也没有使用 MySQL Cluster，所以我也没有在 MySQL Cluster 环境中使用 Query Cache 的实际经验，只是 MySQL 文档中说明确实可以在 MySQL Cluster 中使用 Query Cache。从 MySQL Cluster 的原理来分析，也觉得应该可以使用，毕竟 SQL 节点和数据节点比较独立，各司其职，只是 Cache 的失效机制会要稍微复杂一点。

相关文章

• 2009-10-09 -- mysql cache功能小记
• 2009-08-27 -- Query Cache，看上去很美

方法一：

步骤一 命令行执行：mysqldump –opt -hlocalhost -uroot -p*** –default-character-set=latin1 dbname > /usr/local/dbname.sql

步骤二 将 dbname.sql文件中的create table语句的CHARSET=latin1改为CHARSET=utf8

步骤三 在dbname.sql文件中的insert语句之前加一条’set names utf8;’

步骤四 将dbname.sql转码为utf-8格式，建议使用UltraEditor，可以直接使用该编辑器的’转换->ASCII到UTF-8(Unicode编辑)’，或者将文件另存为UTF-8(无BOM)格式

步骤五 命令行执行：mysql -hlocalhost -uroot -p*** –default-character-set=utf8 new_dbname < /usr/local/dbname.sql

总结：这种方法有个致命之处就是当数据中有大量中文字符和其他特殊符号字符时，很有可能导致在[步骤五]时报错导致无法正常导入数据，如果数据库比较大可以分别对每张表执行上述步骤

方法二（推荐大家使用）：

为了解决第一种方法中总结时说到的问题，在网上苦苦查找了一天资料才东拼西凑的搞出一个比较稳妥的解决方法

步骤一 将待导出的数据表的表结构导出（可以用Phpmyadmin、mysqldump等，很简单就不说了），然后将导出的create table语句的CHARSET=latin1改为CHARSET=utf8，在目标库newdbname中执行该create table语句把表结构建好，接下来开始导出-导入数据

步骤二 命令行：进入mysql命令行下，mysql -hlocalhost -uroot -p*** dbname

步骤三 执行SQL select * from tbname into outfile ‘/usr/local/tbname.sql’;

步骤四 将tbname.sql转码为utf-8格式，建议使用UltraEditor，可以直接使用该编辑器的’转换->ASCII到UTF-8(Unicode编辑)’，或者将文件另存为UTF-8(无BOM)格式

步骤五 在mysql命令行下执行语句 set character_set_database=utf8;  注：设置mysql的环境变量，这样mysql在下一步读取sql文件时将以utf8的形式去解释该文件内容

步骤六 在mysql命令行下执行语句 load data infile ‘tbname.sql’ into table newdbname.tbname;

注意：千万不要忘了第四步

采用第二种方法，所有数据均正常导入，且格式转换成功没有乱码

相关文章

• 2010-02-07 -- MySQL库目录下db.opt文件的作用
• 2009-07-15 -- 数据库字符集修改
• 2008-12-15 -- 调用存储过程时报错:Illegal mix of collations
• 2008-12-03 -- 深入Mysql字符集设置
• 2008-09-21 -- 如何更改MySQL的默认字符集
• 2008-09-21 -- 小谈MySQL字符集
• 2008-09-18 -- mysql连接通道中的字符集和校验规则
• 2008-09-18 -- mysql字符集与校验规则的设置
• 2008-09-18 -- mysql的字符集与校验规则概念小介

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
prompt="(\u:mysql1@linuxbyte.org \R:\m)[\d]: "

会产生如下效果:

root@ubuntu:/home/hew# mysql -u hew -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 320
Server version: 5.1.41-3ubuntu12.1 (Ubuntu)
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

(hew:mysql1@linuxbyte.org 21:12)[(none)]: use linuxbyte  #注意这里

Database changed

(hew:mysql1@linuxbyte.org 21:13)[linuxbyte]: use linuxsky; #这里

Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed

(hew:mysql1@linuxbyte.org 21:13)[linuxsky]: #这里

如上所示我们可以在mysql命令行下显示当前的mysql 用户，所在主机，时间和所用的数据库。
这个在关键时刻可以让我们避免很多误操作。

相关文章

• 目前没有相关的文章

突然发现一个问题，感觉很明显，就是很多之前从书上学过了解到的知识，工作中并不会很自然地主动地被想起，而是每次就跟新东西一样，都是在同事的提示后，才恍然大悟，“哦，原来这样，其实，很早就知道这个东西的…..”，基本功不扎实呀！好比，渴了自然就会想到喝水。开始的自信与张扬已是消失殆尽，现在的心态就是：踏实、诚恳、谦虚地去学习，努力做好每件事情。

这一个月无论是工作的压力还是心情的波动，都让我体会颇多。第一次感觉到原来工作是有压力的，以及所背负的责任。我是一个很在意别人看法的人，我希望被每个人所认可，所以每次任务都积极去完成，但由于天生性格的急躁，还是总会弄出些岔子来。尽管开始成熟，但还是缺乏稳重。

下面就和大家抖露抖露我这一个月的“风花雪月”。

1. 头疼的SQL

任务：第一周领导就分配了统计需求的任务。将近20条语句以及数据导出弄了一周。说实话，现在对Tarot库还是一知半解，依然需要现查现看结构注释。

体会：SQL语句的组织并不是很难，刚开始一直被GROUP BY、COUNT()弄的很晕，写SQL是个熟练活，该用什么怎么实现也都很讲究技巧；而重要的是你需要对统计的这个系统本身有更多的了解，也就是业务流是什么，数据在各个表中是一个什么状态，是字典表、业务表还是日志型表，每个字段的确切含义。SQL对我来说几乎就是“零”，功能的实现目前来说都很吃力了，至于执行的性能，更是心有余而力不足，只能后期实际中遇到了再加以改进了。

2. 不小的事故

任务：每周二系统例行维护。对于数据库需要做的是，主库清除前一个月一周内的日志型表中的数据，并在从库进行全备。

体会：由于备份结束后，没有对北方区dump文件进行检查，dump文件只有4K，显然mysqldump出了问题（事实上，dump是正常结束的，困惑？），导致之前主库删除的数据丢失（因为我们的从库开启了log_slave_updates，binlog会记录同步过来所执行的sql语句）。在备份测试机上通过恢复4月的dump文件，将被清除的那一周数据导出，然后用从新做的新dump文件恢复后，将之前导出的数据重新导入到库中，最后在重新做一次全备，得到4.5G的dump文件，tail -n 1 dbname.sql结尾行正常“Dump Completed on …”（感谢realzyy提供的简单快捷的检查方法）。当初觉得，这些历史数据对应用本身并没有影响，只是为运营团队提供后期数据分析，反正已经成功回复，也没有太当回事，之后也没及时向领导汇报，后来领导找我谈话，我才深刻认识到问题的严重性，对于数据一定一定要格外加倍小心，无论是做什么用的，必须保证安全。经过这次风波后，做任何操作我都变得格外小心。做事情的条例很重要，开始的时候，哪怕慢点也要力求稳，不知道不清楚绝对不能操作；我们要知道获得一份信任需要很长的时间，但是让别人放弃你那是瞬间的事情。The first time is also the last time…Keep in mind…Be careful….Fish….我现在时刻背负着被开的风险，只能靠以后积极努力的工作去挽回失去的信任。

3. 完善备份

任务：定期全备与每日增量备份脚本的测试与修改。

体会：一周都在修改shell脚本，有脚本帮我们去完成重复性的操作既方便又可靠，但是脚本不是能实现你的工能就可以了，事实上，我们更想知道执行的结果正常与否，这就需要脚本能够收集这些信息并反馈给我们，所以要生成日志文件便于我们查看，或以邮件方式将报告发给我们。

关于mysqldump的参数选择，我最近体会颇深。之前写过一篇MySQL企业级备份与恢复，现在想下就是标题当，什么狗屁。 mysqldump什么参数都不加，一看就不专业。突然想起来之前去飞信面试，周师傅问我，mysqldump备份的时候加什么参数吗，我很自豪的回答，什么都不加呀，那个默认opt就很好了，现在想想脸红呀，差的不是一点。

4. 语句分析

任务：开发人员反应客服系统中一条SQL语句执行过长，导致系统超时报错，同时呢，还会导致主从复制不一致（Seconds_Behind_Master超过300秒nagios会报警）。

体会：这条语句是做分页的，每次显示50条记录，同时按时间排序，3个表(record_goods,goods,characters)做关联，其中一个是物品交易表(record_goods)，有千万条记录，每次执行该条语句时，我在从库的服务器端show processlist\G去查看该条语句的执行状态，发现stat是locked，被锁住了，同时发现slave中的sql_thread线程也同时有一条update语句locked在那里，但是，惊奇的发现这个被锁的表，却是那3个表中的其中物品信息表(goods)，然后我又show table status goods\G，发现该表竟是MyISAM的，而且那个update time时间在不停的更新。这下明白了，从库保持同步主库上goods表的update操作，这样就会对goods表叫锁，它又是MySIAM表，自然表级锁，当我们在执行那条查询语句时，如果执行时间过长，update操作就会被锁住，导致从库同步落后时长增加，导致nagois报警。之前提到，物品交易表非常庞大，后来我们采用自查询，先对record_goods表和characters表做表联接，查出符合条件间的50条记录，然后再将产生的结果集与goods表做关联查出最后系统所需的结果，执行时间不到1秒。我要从新更新我脑子里面之前那些经验性的总结，至于是表联接性能好，还是子查询性能好，实际中怎么好就怎么来吧。

这一个月的体会就是这么多了，下次再继续分享我的DBA初体验。

相关文章

• 2009-03-30 -- DBA未来的发展方向

2、执行一个SQL，但SQL语句过大或者语句中含有BLOB或者longblob字段。比如，图片数据的处理
解决方案：
在my.cnf文件中添加或者修改以下变量：
max_allowed_packet = 10M(也可以设置自己需要的大小)
max_allowed_packet 参数的作用是，用来控制其通信缓冲区的最大长度。

相关文章

• 2008-09-14 -- MySQL server has gone away问题及其解决

涉及到的概念：Buffer Pool简称BP，Dirty Page，Log file，Flush，innodb tablespace。

1. 什么是Double Write

在InnoDB将BP中的Dirty Page刷（flush）到磁盘上时，首先会将Page刷到InnoDB tablespace的一个区域中，我们称该区域为Double write Buffer。在向Double write Buffer写入成功后，再择机将数据拷贝到正在的数据文件对应的位置。

咋一看，这个过程有些多余

2. 为什么需要Double Write

InnoDB中有记录（Row）被更新时，先将其在Buffer Pool（简称BP）中的page更新，并将这次更新记录到Log file中，这时候BP中的该page就是被标记为Dirty。在适当的时候（BP不够、系统闲置等），这些Dirty Page会被flush到磁盘上。

试想，在某个Dirty Page（一般是16K）flush的过程中，发生了系统断电（或者OS崩溃），16K的数据只有8K被写到磁盘上，这种现象被称为（partial page writes、torn pages、fractured writes）。一旦partial page writes发生，那么在InnoDB恢复时就很尴尬：在InnoDB的Log file中虽然知道这个数据页被修改了，但是却无法知道这个页被修改到什么程度，和这个页面相关的redo也就无法应用了。

举个例子：在InnoDB的log file中有如下Log：

Log sequence number 0 4285149977
Log sequence number 0 4287355447
Log sequence number 0 4289260680
Log sequence number 0 4291279900
Log sequence number 0 4293359020

其中第1、3个Log修改了该page，但是在断电时，BP中该page只被flush了一部分。那么InnoDB是无法决定上面的Log是否应该被应用的。这时，数据就出现了不一致。

所以，Log file的有效应用，前提是InnoDB的数据文件中的Page是一致的。

简而言之，Double write就是为了避免Partial page writes而设计的。

3. Double Write对性能的影响

系统需要将数据写两份，一般认为，Double Write是会降低系统性能的。peter猜测可能会有5-10%的性能损失，但是因为实现了数据的一致，是值得的。Mark Callaghan认为这应该是存储层面应该解决的问题，放在数据库层面无疑是牺牲了很多性能的。

事实上，Double Write对性能影响并没有你想象（写两遍性能应该降低了50%吧？）的那么大。在BP中一次性往往会有很多的Dirty Page同时被flush，Double Write则把这些写操作，由随机写转化为了顺序写。而在Double Write的第二个阶段，因为Double Write Buffer中积累了很多Dirty Page，所以向真正的数据文件中写数据的时候，可能有很多写操作可以合并，这样有可能会降低Fsync的调用次数。

基于上面的原因，Double Write并没有想象的那么糟。另外，Dimitri在测试后，发现打开和关闭Double Write对效率的影响并不大。

4. 相关参数与状态

是否打开了double write:

root@(none) 07:16:16>show variables like "%double%";
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| innodb_doublewrite | ON    |
+--------------------+-------+

Double write的使用情况：

root@(none) 07:15:50>SHOW STATUS LIKE "%innodb_dblwr%";
+----------------------------+-----------+
| Variable_name              | Value     |
+----------------------------+-----------+
| Innodb_dblwr_pages_written | 145373349 |
| Innodb_dblwr_writes        | 2249336   |
+----------------------------+-----------+

上面可以看到，从BP共Flush了145373349个Pages到double write buffer中；一共调用了2249336次write写到真正的数据文件。可见，相当于每次write合并了 145373349 / 2249336 = 64.6次Flush。（这就是为什么double write buffer为什么并不会对效率有很大影响的原因）

5. 我的看法

在某些文件系统（ZFS等）层面能够保证不出现Partial page writes时，可以关闭Double Write。因为它对性能影响并不大，一般情况都建议打开，毕竟带来的数据安全性保障可能是我们更关心的。

参考文献：

[0]. Manual about Double Write

[1]. Innodb Double Write

[2]. Do you need the InnoDB doublewrite buffer

[3]. MySQL Performance: InnoDB Doublewrite Buffer Impact

相关文章

• 2010-08-04 -- InnoDB主键设计
• 2010-03-09 -- Innodb 表和索引结构
• 2010-03-09 -- InnoDB线程并发检查机制
• 2009-12-20 -- Innodb如何使用内存
• 2009-12-20 -- Innodb文件表空间结构
• 2009-12-12 -- InnoDB的”替代品”：Percona XtraDB
• 2009-09-25 -- Innodb表空间page size的选择
• 2009-09-03 -- MySQL InnoDB性能调整的一点实践
• 2009-08-18 -- 随机主键对InnoDB插入性能的影响
• 2009-08-18 -- InnoDB之Dirty Page、Redo log

MySQL半同步流程设计图

在开启MySQL半同步的时候，需要至少一个开启了半同步的slave。在master提交一个写事务之后，master会block这个事务，直到至少一个slave确认已经接受到了该复制事件，这时master才想应用程序确认提交成功。否则超时中断半同步，直到重新满足条件开启。

在master提交事务之后，而slave未来得及接收复制事件，这时候master crash的话，应用程序会切换到slave上，并重新发起事务，这正好是我们所需要的，满足高可用的初衷。但是这里存在一个缺陷，那就是在master恢复之后，原来的事务已经提交，这时候复制会出现问题。

解决办法：在原来的master恢复之后数据重做(推荐)，或者跳过重复数据错误。

相关文章

• 目前没有相关的文章

1) 首先，假设只有一个库；多个库的情况也是类似，无非就是循环
2) 计算SQL文件总行数
3) 计算SQL文件总大小
4) 设定每个切分文件最大尺寸
5) 初始化表结构
6) 循环处理SQL，按照切分文件最大尺寸切分成多个小文件
7) 并发导入多个小文件

上述方法中，如果数据表是 MyISAM 表，则并发导入没有问题，但如果是 InnoDB 表，则会有表级锁 AUOT-INC 导致并发效率不高的麻烦，尽管如此，那也比单个文件串行导入来的快一些。想要避免这个麻烦，就得采用 MySQL 5.1 版本了，因为在 5.1 中，改进了 AUTO-INC 的处理方式，规避了表级锁，很大程度提高了并发效率。
2、实际测试
事先设定：最大并大导入线程是16个。
2.1 MySQL 5.0.67 版本

innodb_flush_log_at_trx_commit = 1
串行导入：01:51:34
并行导入：01:25:05
innodb_flush_log_at_trx_commit = 0
串行导入：01:49:36
并行导入：01:11:29

2.2 MySQL 5.1版本

innodb_flush_log_at_trx_commit = 1, innodb_autoinc_lock_mode = 0
串行导入：01:52:28
并行导入：01:38:13
innodb_flush_log_at_trx_commit = 1, innodb_autoinc_lock_mode = 1
串行导入：01:54:55
并行导入：01:26:24
innodb_autoinc_lock_mode = 0
并行导入：01:38:13
innodb_autoinc_lock_mode = 1
并行导入：01:05:51

更加详细的测试就不再做了。
3、小结
从上面的测试结果可以看到，MySQL 5.1在AUTO-INC锁方面的改进还是非常大的，对于想要提升并发性能，同时应用相对不是太复杂，并且不担心会碰到bug的童鞋可以多多尝试下。
由于众所周知的缘故，相关的脚本就不发布了，有需要的童鞋请加入MSN群讨论。

相关文章

• 目前没有相关的文章

    对于MySQL把有的存储引擎都是把表结构的定义存放到.frm文件中。但对于Innodb表同时有一个内部的字典存放到表空间中。所以对于Innodb表不能单纯的移动.frm在不同的MySQL事例下。对于Innodb引擎的表，如果MySQL 删除相应的表或数据库，同时会删除相应的.frm及在表空间的相应的字典信息。在.frm文件只是用来定义表的结构，Innodb把数据和索引都存放到了表空间中。

    聚集索引和次要索引：

    每一个Innodb表都有一个聚集索引，这个聚信索引和行数据存在一起。

    可以用来做聚集索引的列：

如果有声明了主建(primary key)，则这个列可以做为表的主建。 如果没有声明主建，MySQL会用一个唯一索引(UNIQUE)而且是不为空的列做为主建，成为该表的聚信索引。 如果没声明主建，同时也没合适的唯一的索引，Innodb内部会产生一个隐藏的聚集索引:RowID。这个RowID在Innodb的多版本中曾提到过。这个RowID是在插入时产生，并且是自增的增加。所以也是按顺序增长存放。

    由于聚集索引和行数据存放一起(在同一个数据页中)，所以利用聚集索引访问数据行时，非常的快，同一个数据页在访问索引时，已经把页加载到Buffer中，在访问数据时，等于了一个顺序IO的访问（内存中完成）。大多数情况下索引和数据都不在一块（MyISAM，数据和索引存到不同的文件中），而聚集索引是有结构的通常是按顺序存放，同时和数据存放在一起，利用索引索引访问大表的数据可以节省许多IO。

    对于Innodb次要的索引会包含聚信索引，查询在使用次要索引时，找到聚集索引信息，然后利用聚集索引信息访问行。所以，如果聚集索引过长，会造成空间浪费严重。另外，如果对表或是区间进行Count操作的话，大多数情况较短的次要索引比基于聚集索引快。对于Innodb的聚集索引选择，尽量选择比较短的列做为聚集索引列，是一个好的设计习惯。

    索引的物理结构：

    Innodb的索引以B-tree的形式存到各个叶点上。索引叶点页的大小默认为16K，当有什么的索引插入叶点时，该叶点至少会保留1/16的空闲空间，用于将来该叶点的索引更新或是插入。

    对于顺序写入的索引（无论是递增或是递减，顺序的就行），索引叶点可以达到15/16满。如果是随机的索引写入行为，叶点只会达到1/2到15/16满。当叶点填充在1/2以下满，或是被删除到1/2下满时，Innodb会缩短索引树，试图释放该叶点，该叶点可以被继续写入数据。

设计中的Tips：

    因为Innodb表的数据是依赖于聚集索引顺序存放，同时聚集索引和数据一块存储，普通索引也需要存放一份聚集索引。所以对于聚集索引的设计尽量按顺序写入，必免数据分页，行迁移等对性能影响的现象。另外聚集索引要设计的尽可能短。从设计上必须锁的时间，大量随机IO的出现。

    如对于监控（或是股票类的信息）可以利用时间和类型构成聚集索引，让相关性高的数据尽可能位到一块。以便读取时可以利用顺序IO读取到相应的数据。最好的情况，相关性高的数据在一个Page上，这样读取的效果更好。基于Innodb聚集索引的特性，在设计上也需要考虑利用一下优势，必免其不好的一方面从而达到最佳性能。

相关文章

• 2008-11-18 -- Innodb 索引结构了解 - Innodb Index Structure
• 2010-08-04 -- InnoDB主键设计
• 2010-04-13 -- InnoDB Double write
• 2010-03-09 -- InnoDB线程并发检查机制
• 2009-12-20 -- Innodb如何使用内存
• 2009-12-20 -- Innodb文件表空间结构
• 2009-12-12 -- InnoDB的”替代品”：Percona XtraDB
• 2009-11-18 -- Memory & MyISAM 引擎小注意！
• 2009-09-25 -- Innodb表空间page size的选择
• 2009-09-13 -- Mysql combine index

在新的MySQL线程调用Innodb接口前，Innodb会检查已经接受的请求线程数，如已经超过innodb_thread_concurrency设置的限制，则该请求线程会等待innodb_thread_sleep_delay微秒后尝试重新请求，如果第二次请求还是无法获得，则该线程会进入线程队列休眠。重试两次的机制是为了减少CPU的上下文切换的次数，以降低CPU消耗，这和Oracle中latch的spin机制是同样的道理。如果请求被Innodb接受，则会获得一个次数为innodb_concurrency_tickets(默认500次)的通行证，在次数用完之前，该线程重新请求时无须再进行前面所说innodb_thread_concurrency的检查。

上述检查逻辑在源码storage/innobase/srv/srv0srv.c(Innodb很多参数都可以在该文件中找到定义)的srv_conc_enter_innodb函数中，有兴趣的可以仔细阅读一下，代码比较浅显，不难理解。另外，如果是一个已经持有lock的线程，则通过调用srv_conc_force_enter_innodb函数可以无视该检查，这是为了避免线程长时间持有锁影响性能，且可能增加死锁的机率。除此之外，slave线程也是有无视检查直接通行的权限。

简单思考一下上述机制，可以得出一个初步的推论：在数据库并发请求较小的情况下，从性能上来说禁用检查机制应该是更好的，毕竟执行检查机制本身也需要加锁(Mutex)。当并发线程很高的情况下，则开启检查机制对性能更有利。至于具体innodb_thread_concurrency设置为多少，可能就需要在不同的条件下实际的做一下测试了，不同的硬件环境，不同的MySQL版本和Innodb版本，应该都会有一些区别。

源代码中对于innodb_thread_concurrency参数的注释如下：

/* The following controls how many threads we let inside InnoDB concurrently:
threads waiting for locks are not counted into the number because otherwise
we could get a deadlock. MySQL creates a thread for each user session, and
semaphore contention and convoy problems can occur withput this restriction.
Value 10 should be good if there are less than 4 processors + 4 disks in the
computer. Bigger computers need bigger values. Value 0 will disable the
concurrency check. */

ulong   srv_thread_concurrency  = 0;

因为检查机制需要Mutex保护(Mutex-based Model)，所以开启检查本身也有性能消耗，并且扩展性也会受到限制，在MySQL5.4版本中引入了一种新的机制（Timer-based Model），这里就不讨论了，有兴趣的可以参考这里(需要翻墙)，实际上XtraDB存储引擎里已经包含Timer-based Model，通过参数innodb_thread_concurrency_timer_based可以开启，默认为OFF。在MySQL5.4的srv0srv.c的源代码中的注释中，可以看到Google和Percona的版权声明，看来MySQL5.4中吸引了很多第三方的改进代码，值得期待。

相关文章

• 2010-08-04 -- InnoDB主键设计
• 2010-04-13 -- InnoDB Double write
• 2010-03-09 -- Innodb 表和索引结构
• 2009-12-20 -- Innodb如何使用内存
• 2009-12-20 -- Innodb文件表空间结构
• 2009-12-12 -- InnoDB的”替代品”：Percona XtraDB
• 2009-09-25 -- Innodb表空间page size的选择
• 2009-09-03 -- MySQL InnoDB性能调整的一点实践
• 2009-08-18 -- 随机主键对InnoDB插入性能的影响
• 2009-08-18 -- InnoDB之Dirty Page、Redo log

1、Lost connection to MySQL server at ‘reading initial communication packet’：
这个主要是因为DNS不稳定导致的。如果做了网络隔离，MySQL处于一个相对安全的网络环境，那么开启skip-name-resolve选项将会最大程度避免这个问题。

2、Lost connection to MySQL server at ‘reading authorization packet’：
从MySQL获取一个可用的连接是多次握手的结果。在多次握手的过程中，网络波动会导致握手失败。增加connect_timeout可以解决这个问题；然而增加connect_timeout并不能防止网络故障的发生，反而会引起MySQL线程占用。最好的解决办法是让mysqldump重新发起连接请求。

3、Lost connection to MySQL server during query：
这个问题具备随机性，而淘宝MySQL的应用场景决定了我们无法多次备份数据以便重现问题。
然而我们注意到这个问题一般会在两种情况下会发生。一种是mysqldump **** | gzip ****；另外一种是mysqldump **** > /nfs-file
注意，不管是gzip还是nfs都有一种特点，那就是它们影响了mysqldump的速度。从这个角度思考，是不是mysqldump从MySQL接受数据包的速度不够快导致Lost connection to MySQL server during query错误呢？

为了定位到问题，我搭建了一个测试环境：
test@192.168.0.1：3306
CREATE TABLE `test` (
`id` bigint(20) NOT NULL auto_increment,
`b` varchar(2000) default NULL,
`c` varchar(2000) default NULL,
`d` varchar(2000) default NULL,
`e` varchar(2000) default NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

insert into test(b,c,d,e) values (lpad(’a’,1900,’b’), lpad(’a’,1900,’b’), lpad(’a’,1900,’b’), lpad(’a’,1900,’b’));
多次复制数据使测试环境达到一定数据量。

192.168.0.2：
编写一个c++程序
#include <stdio.h>
#include <mysql.h>

using namespace std;

int main()
{
MYSQL conn;
MYSQL_RES *result;
MYSQL_ROW row;
my_bool reconnect = 0;

mysql_init(&conn);
mysql_options(&conn, MYSQL_OPT_RECONNECT, &reconnect);

if(!mysql_real_connect(&conn, “192.168.0.1″, “test”, “test”, “test”, 3306, NULL, 0))
{
fprintf(stderr, “Failed to connect to database: %s\n”, mysql_error(&conn));
exit(0);
}
else
{
fprintf(stdout, “Success to connect\n”);
}

mysql_query(&conn, “show variables like ‘%timeout%’”);
result = mysql_use_result(&conn);
while(row=mysql_fetch_row(result))
{
fprintf(stdout, “%-10s: %s\n”, row[0], row[1]);
}
mysql_free_result(result);
fprintf(stderr, “\n”);

mysql_query(&conn, “select SQL_NO_CACHE * from test.test”);
result = mysql_use_result(&conn);
while((row=mysql_fetch_row(result))!=NULL)
{
fprintf(stderr, “Error %d: %s\n”, mysql_errno(&conn), mysql_error(&conn));
fprintf(stdout, “%s\n”, row[0]);
sleep(100);
}
fprintf(stderr, “Error %d: %s\n”, mysql_errno(&conn), mysql_error(&conn));
mysql_free_result(result);
mysql_close(&conn);
return 1;
}

在这段代码里，sleep函数用来模拟NFS的网络延迟和gzip的运算时间。执行一段时间之后，Lost connection to MySQL server during query出现了，程序意外终止。在数据处理足够快的情况下，又会是怎样的结果？

将sleep的时间改为1，重新编译后发现程序能够完整跑完。根据《MySQL Timeout解析》上对net_write_timeout的解释，我们可以发现，mysqldump处理数据过慢（NFS、gzip引起）会导致MySQL主动断开连接，此时mysqldump就会报Lost connection to MySQL server during query错误。经过多次测试，确定这个错误是由于net_write_timeout设置过短引起。

相关文章

• 2009-08-11 -- source sql文件报错
• 2009-06-07 -- mysqldump 导出触发器遇到的问题
• 2009-02-23 -- 改良版本mysqldump来备份MYSQL数据库
• 2008-10-24 -- mysqldump的几个主要选项探究

先看一下比较常见的Timeout参数和相关解释：
connect_timeout
The number of seconds that the mysqld server waits for a connect packet before responding with Bad handshake.
interactive_timeout
The number of seconds the server waits for activity on an interactive connection before closing it.
wait_timeout
The number of seconds the server waits for activity on a noninteractive connection before closing it.
net_read_timeout
The number of seconds to wait for more data from a connection before aborting the read.
net_write_timeout
The number of seconds to wait for a block to be written to a connection before aborting the write.

从以上解释可以看出，connect_timeout在获取连接阶段（authenticate）起作用，interactive_timeout和wait_timeout在连接空闲阶段（sleep）起作用，而net_read_timeout和net_write_timeout则是在连接繁忙阶段（query）起作用。

获取MySQL连接是多次握手的结果，除了用户名和密码的匹配校验外，还有IP->HOST->DNS->IP验证，任何一步都可能因为网络问题导致线程阻塞。为了防止线程浪费在不必要的校验等待上，超过connect_timeout的连接请求将会被拒绝。

即使没有网络问题，也不能允许客户端一直占用连接。对于保持sleep状态超过了wait_timeout（或interactive_timeout，取决于CLIENT_INTERACTIVE标志）的客户端，MySQL会主动断开连接。

即使连接没有处于sleep状态，即客户端忙于计算或者存储数据，MySQL也选择了有条件的等待。在数据包的分发过程中，客户端可能来不及响应（发送、接收、或者处理数据包太慢）。为了保证连接不被浪费在无尽的等待中，MySQL也会选择有条件（net_read_timeout和net_write_timeout）地主动断开连接。

这么多Timeout足以证明MySQL是多么乐于断开连接。而乐于断开连接的背后，主要是为了防止服务端共享资源被某客户端（mysql、mysqldump、页面程序等）一直占用。

相关文章

• 目前没有相关的文章

另外要说明的是，如果你是通过alter databases(schema) 命令更改的数据库默认属性，那么现有的表的默认字符集和排序规则不受影响。

通过创建数据库指定数据库的默认字符集和排序规则：

也可以通过alter database修改

相关文章

• 2010-06-01 -- mysql latin1转utf8 的两种方法
• 2009-07-15 -- 数据库字符集修改
• 2008-12-15 -- 调用存储过程时报错:Illegal mix of collations
• 2008-12-03 -- 深入Mysql字符集设置
• 2008-09-21 -- 如何更改MySQL的默认字符集
• 2008-09-21 -- 小谈MySQL字符集
• 2008-09-18 -- mysql连接通道中的字符集和校验规则
• 2008-09-18 -- mysql字符集与校验规则的设置
• 2008-09-18 -- mysql的字符集与校验规则概念小介

    译这个文章的目的：

    　　最近经常被问起Innodb是如何使用内存的。该问题早已被原MySQL公司的Vadim论证过。我这里译一下他的文章供大家参考。

    开始：

    　　这里有许多关于Innodb如何使用内存的问题。我这里将会以innodb启动时的分配情况做一个解释。一些重要的概念：

    　　NBLOCKS＝Innodb_buffer_pool有多个页(block)＝innodb_buffer_pool_size/16384(16k)

     　OS_THREADS= if ( innodb_buffer_pool_size >= 1000Mb) = 50000

     　　else if (innodb_buffer_pool_size >= 8Mb) = 10000

    　　 else = 1000 (该值只用在*nixes系统上，对于Windows有一点小的区别计算OS_THREADS)

    所以Innodb 使用的内存包括：

    　innodb_buffer_pool_size

     innodb_additional_mem_pool_size

     innodb_log_buffer_size

     adaptive index hash ,size (innodb buffer 索引管理区)= innodb_buffer_pool_size/64

     system dictionary hash,size(innodb内部字典区) = 6 * innodb_buffer_pool_size/512

     memory for sync_array,size(用于Innodb内部syncronzation的开销)=OS_THREAD * 512

     memory for os_event,size(用于innodb内存的syncronzation的开销)=OS_THREAD * 216

     memory for locking system(内存的锁管理系统),size = 5 * 4 *NBBLOCKS

     最终得到innodb内存使用的计算公式为：

     Innodb_buffer_pool_size + innodb_log_buffer_size + innodb_additional_mem_pool_size + 812/16384 * innodb_buffer_pool_size + OS_THREADS * 368

     对于812/16384 * Innodb_buffer_pool_size 可以简单的用 innodb_buffer_pool_size / 20　计算，

    对于OS_THREADS * 368　　

     OS_THREADS * 368 = 17.5 MB if innodb_buffer_pool_size > 1000MB

     OS_THREADS * 368 = 3.5 MB if innodb_buffer_pool_size > 8MB

    举一个例子：

    　　 如果你的innodb_buffer_pool_size有1500MB,innodb_additional_mem_pool_size =20 MB,innodb_log_buffer_size = 8M,

     　　Innodb 将会向系统申请内存为= 1500M + 20M + 8M + 1500/20 M +17.5 = 1620.5M

    　　根据以上的条件可以算出Innodb最根本最需要多少内存，这样对于服务器的内存使用也可以有一个规划了。

相关文章

• 2010-08-04 -- InnoDB主键设计
• 2010-04-13 -- InnoDB Double write
• 2010-03-09 -- Innodb 表和索引结构
• 2010-03-09 -- InnoDB线程并发检查机制
• 2009-12-20 -- Innodb文件表空间结构
• 2009-12-12 -- InnoDB的”替代品”：Percona XtraDB
• 2009-09-25 -- Innodb表空间page size的选择
• 2009-09-03 -- MySQL InnoDB性能调整的一点实践
• 2009-08-18 -- 随机主键对InnoDB插入性能的影响
• 2009-08-18 -- InnoDB之Dirty Page、Redo log

    show variables like \’%sche%\’;

    将事件计划开启

    set global event_scheduler =1;

    创建存储过程test

     CREATE PROCEDURE test ()

     BEGIN

     update examinfo SET endtime = now() WHERE id = 14;

     END;

     创建event e_test

     create event if not exists e_test

     on schedule every 30 second

     on completion preserve

     do call test();

     每隔30秒将执行存储过程test,将当前时间更新到examinfo表中id=14的记录的endtime字段中去.

     关闭事件任务

     alter event e_test ON

     COMPLETION PRESERVE DISABLE;

     开户事件任务

     alter event e_test ON

     COMPLETION PRESERVE ENABLE;

     以上测试均成功,测试环境为mysql 5.4.2-beta-community mysql community server(GPL)

相关文章

• 目前没有相关的文章

     表空间是在配置文件中定义的几个文件简单的耦合起来，在使用中互不可少（少一个就面临DB完蛋的危险）。对于共享表空间无法确定表所在的表空间上。

     独立表空间可以做到每个表有自已的表空间（羞一下）。

     针对共享表空间，表空间中包括：回滚段,段（segment），区域（extent),数据页(page size)在表空间的体现为：

     表空间由默认16k的数据页面（page)组成，每64个连续的页面组成一个区域（extent,Oracle里熟悉的一个东东）。对于表空间的“文件(file)”在Innodb中被称为段(segment)。 回滚段(rollback segment）是一个特殊的例子，实际上rollback segment包含了多个段。对于Innodb表的索引都被分配成两个段：一个是为了 B-tree 的无叶结点(non-leaf nodes)，另一个是为了叶结点(leaf nodes)。

     这是为了达到包含数据的叶结点的更好的顺序(sequentiality for the leaf nodes)。

     当表空间中的一个段增长时，InnoDB 为它个别地分配最初的 32 个页面。之后 InnoDB 再分配段的整个区域(extents)。InnoDB 会以每次 4 个区域(extents)来增加一个大段以确保数据的良好顺序。

     表空间中的某些页面包含其它页面的位图(bitmaps)，所以在 InnoDB 表空间内的一些区域(extents)不能以一个整体分配给段，而只能作为个体页面。

     当发出一个查询 SHOW TABLE STATUS FROM … LIKE … 来询问表空间的剩余空间时，InnoDB 将报告表空间中所有空闲区域(extents)中确实可用的部分。InnoDB 通常会保留一些区域用于 clean-up 和其它的内部目的；这些保留的区域并不包含在剩余可用空间中。

     当从一个表中删除数据时，InnoDB 将收缩 B-tree 中相应的索引。这是依赖于释放个别的页面或区域(extents)以让其他用户使用剩余空间的删除模式。 移除(drop)一个表或删除所有记录可以保证释放空间给其他用户，但是删除记录行只有在事务回滚或 consistent read 后并不需要时才会被物理的移除

     对于独立表空间也是存一样的概念和行为，唯一区别就是每个表的数据存到指定的表空间中，rollback segment不和数据的segment在一个竞争。使用独立表空间的一个好处就是可以使数据分布相对于磁盘上更连续一点。

相关文章

• 2010-08-04 -- InnoDB主键设计
• 2010-04-13 -- InnoDB Double write
• 2010-03-09 -- Innodb 表和索引结构
• 2010-03-09 -- InnoDB线程并发检查机制
• 2009-12-20 -- Innodb如何使用内存
• 2009-12-12 -- InnoDB的”替代品”：Percona XtraDB
• 2009-09-25 -- Innodb表空间page size的选择
• 2009-09-03 -- MySQL InnoDB性能调整的一点实践
• 2009-08-18 -- 随机主键对InnoDB插入性能的影响
• 2009-08-18 -- InnoDB之Dirty Page、Redo log

    如果是INNODB的话.其实是无法修改库名的.网上瞎咧咧的什么RENAME DATABASE或者ALTER DATABASE都是不行的

    一种方法是比较保守的.直接把老库的内容mysqldump到新库里面

    还有一种类似上面方法.先alter table 的存储引擎到MyISAM,然后改了库目录的名字,然后再改回来INNODB.

    最后一种方法还是比较好的.这边详细写一下.

    假设源库名是’srcdb’,目标库名是’trgdb’

    首先创建目标库

    create database trgdb;

    获取所有源库的表名

    use information_schema;

    select table_name from TABLES where TABLE_SCHEMA=’srcdb’;

    然后按照以下命令一个个修改

    rename table srcdb.[tablename] to trgdb.[tablename];

    一个个执行下来之后表就转到新的库里面了.

相关文章

• 目前没有相关的文章

XtraDB是Percona Team在InnoDB的基础上开发出来的一个更加强大的存储引擎，它百分百的兼容InnoDB，我们可以用XtraDB来替代为MySQL的发展做出历史性贡献的InnoDB，新的XtraDB引擎将具有更加强大的性能优势，以及良好的扩展性和一些新特性。

Percona于2008年12月16日正式对外公布Percona XtraDB存储引擎，当时版本为1.0.2-1。在09年有相继发布了release 3/4/5/8，目前最新的版本为Percona-XtraDB 1.0.4-8。

安装XtraDB存储引擎

XtraDB的安装有这么几种：一是现成的RPMS包安装，不过这些包仅限于x86_64位RedHat/CentOS 4/5系统下，而且MySQL的版本为5.1.30；还有就是通过整体编译MySQL源码包的安装,即将新的XtraDB引擎的代码整合到MySQL的源码中，进行重新编译。前面这两种都需要重新搭建MySQL数据库，例外还有一种，就是动态的将XtraDB加载进正在运行MySQL中，这个看上去很符合生产的要求。

下面我们就来介绍Linux系统下，源码包的安装方法，具体步骤如下：

1.下载MySQL的源码安装包。http://dev.mysql.com/downloads/mysql/5.1.html#source

2.下载Percona XtraDB的源码安装包。https://launchpad.net/percona-xtradb/+download

3.编译安装MySQL

shell>tar -xvf mysql-5.1.35.tar.gz

shell>cd mysql-5.1.35/storage

shell>tar -xvf percona-xtradb-1.0.4-8.tar.gz

shell>rm -rf innobase

shell>mv percona-xtradb-1.0.4-8 innobase

shell>cd ..

shell>./configure -prefix=/usr/local/mysql -with-plugins=innobase && make && make install

shell> cp support-files/my-medium.cnf /etc/my.cnf

shell> cd /usr/local/mysql

shell> chown -R mysql.mysql .

shell> bin/mysql_install_db -user=mysql

shell> chown -R root .

shell> chown -R mysql var

shell> bin/mysqld_safe -user=mysql &

4.验证XtraDB引擎的100%兼容Innodb。

shell> mysql -uroot -p < eiken_uat_backup.090803230101  (将生产数据库导入新的MySQL)

mysql> show create table user_role\G

*************************** 1. row ***************************

       Table: user_role

Create Table: CREATE TABLE `user_role` (

  `user_name` varchar(100) NOT NULL,

  `role_name` varchar(25) NOT NULL,

…omit….

) ENGINE=InnoDB DEFAULT CHARSET=latin1

1 row in set (0.00 sec)

(经测试，所有应用一切正常。)

mysql> create table xtradb_tb(id int(3),engine_name char(120)) engine=innodb; （创建一个使用XtraDB引擎的表）

Query OK, 0 rows affected (0.00 sec)

mysql> show create table xtradb_tb\G

*************************** 1. row ***************************

       Table: xtradb_tb

Create Table: CREATE TABLE `xtradb_tb` (

  `id` int(3) DEFAULT NULL,

  `engine_name` char(120) DEFAULT NULL

) ENGINE=InnoDB DEFAULT CHARSET=latin1

1 row in set (0.00 sec)

（NOTE：如果你要使用XtraDB这个引擎，engine的值依然要设置成InnoDB。）

比较

最后，我们简要比较一下XtraDB与InnoDB之间都有哪些变化。分别连上配有不同引擎的数据库服务。比较如下：

1.INFORMATION_SCHEMA中的表数量发生明显变化。

XtraDB ：42个（增加了13项INNODB开头的表和一个XTRADB_ENHANCEMENTS表，改表中记录逐一介绍了新的XtraDB对InnoDB所做的各项改进）

InnoDB ：28个

2. SHOW INNODB STATUS命令的输出内容的增加。

其中，BUFFER POOL AND MEMORY的内容变得更加丰富。

同时，在输出中，我们还会发现，XtraDB在线程的投入上也有很大提高，在InnoDB中FILE I/O的线程仅为4个，而在XtraDB中你会发现为10个，分别是读、写的线程数都各自增加为4个，这对于性能会有很大提升。

P.S.: 其实，第一次听到InnoDB的替代引擎，实在最近的一次面试的时候，当时，一听傻了，在想“InnoDB”什么时候除了替代品啦，我真的太孤陋寡闻了（Hiro听到后一定有要鄙视我了，LOL:>）。后来，查了一下，是真地——Percona XtraDB，出来了！

相关文章

• 2010-08-04 -- InnoDB主键设计
• 2010-04-13 -- InnoDB Double write
• 2010-03-09 -- Innodb 表和索引结构
• 2010-03-09 -- InnoDB线程并发检查机制
• 2009-12-20 -- Innodb如何使用内存
• 2009-12-20 -- Innodb文件表空间结构
• 2009-09-25 -- Innodb表空间page size的选择
• 2009-09-03 -- MySQL InnoDB性能调整的一点实践
• 2009-08-18 -- 随机主键对InnoDB插入性能的影响
• 2009-08-18 -- InnoDB之Dirty Page、Redo log

    如果用来分区的字段和主键不是同一个，则不能分区见很早前的一篇译文mysql 5.1新功能 －－ 按日期分区，如果查询条件中没有正确利用到分区的字段，那么partition的效果为零mysql 5.1.31之前的partition功能有较大的bug，会导致自增字段不能正常自增，怎么个不正常法？auto_increment值会非正常增长，突然比当前的最大id小很多，插入数据时导致duplicate key错误。

    这些问题都能凑合着对付过去，但是partition功能和auto_increment似乎是天生的敌人。从使用习惯上来说，我们会把auto_increment字段设置为主键，这个字段要是unique的才比较稳妥，这个情况下如果希望用其它字段来进行分区的话，几乎就成了不可能的任务。以这张表为例：

    这个时候试图以uid进行分区会怎么样？是以怎样的惨淡结局收场？变通的办法是对自增字段做一些调整，从mysql的手册来看，自增字段不一定要设置成主键，仅仅是普通的index也可以，那么把表结构换成下面这个样子，就可以分区成功。

    我在实际环境中有一张表达到了几亿条数据，如果要用时下流行的sharding策略，必须在代码上做一些改动，当时偷了点懒直接使用partition功能，用了大半年倒也相安无事。只是分区表占用内存相当的大，如果有其它的表经常出现慢查询耗费服务器资源，那么雪崩效应就出现了，所有的查询都会堵塞变得非常慢。

相关文章

• 目前没有相关的文章