Monthly Archives: August 2015

Mysql Innodb的两种表空间方式

Posted on by

要说表空间，Mysql的表空间管理远远说不上完善。换句话说，事实上Mysql根本没有真正意义上的表空间管理。Mysql的Innodb包含两种表空间文件模式，默认的共享表空间和每个表分离的独立表空间。只要在my.cnf里面增加innodb_file_per_table=1就可以从共享表空间切换到独立表空间。当然对于已经存在的表，则需要执行alter table MY_TABLE engine=innodb命令迁移数据。

共享表空间方式

由于是默认的方式，就暂且理解为Mysql官方推荐的方式。相对而言所有的数据都在一个（或几个）文件中，比较利于管理，而且在操作的时候只需要open这一个（或几个）文件即可，相对来说代价很低。

但问题是在数据达到以G为单位来计算的时候优劣逆转。一个大小惊人的文件很不利于管理，而且对于一个如此巨大的文件来说，读写它需要耗费的资源一样巨大。更加令人费解的是，MySQL竟然将索引和数据保存于同一个文件中，索引和数据之间尚存在资源争用，不利于性能的提升。你当然可以通过innodb_data_file_path的配置规划多个表空间文件，但MySQL的逻辑是“用满后增加”，仅仅是一个文件的拆分而已，不能从根本上分离数据和索引。 Continue reading →

[MySQL优化案例]系列 — 索引、提交频率对InnoDB表写入速度的影响

Posted on by

本次，我们通过对比，明明白白的知道索引、提交频率对InnoDB表写入速度的影响，了解有哪些需要注意的。

先直接说几个结论吧：

1、关于索引对写入速度的影响：
a、如果有自增列做主键，相对完全没索引的情况，写入速度约提升 3.11%；
b、如果有自增列做主键，并且二级索引，相对完全没索引的情况，写入速度约降低 27.37%；

因此，InnoDB表最好总是有一个自增列做主键。

2、关于提交频率对写入速度的影响（以表中只有自增列做主键的场景，一次写入数据30万行数据为例）：

a、等待全部数据写入完成后，最后再执行commit提交的效率最高；
b、每10万行提交一次，相对一次性提交，约慢了1.17%；
c、每1万行提交一次，相对一次性提交，约慢了3.01%；
d、每1千行提交一次，相对一次性提交，约慢了23.38%；
e、每100行提交一次，相对一次性提交，约慢了24.44%；
f、每10行提交一次，相对一次性提交，约慢了92.78%；
g、每行提交一次，相对一次性提交，约慢了546.78%，也就是慢了5倍；

因此，最好是等待所有事务结束后再批量提交，而不是每执行完一个SQL就提交一次。

Continue reading →

[MySQL FAQ]系列 — 什么情况下会用到临时表

Posted on by

MySQL在以下几种情况会创建临时表：

1、UNION查询；
2、用到TEMPTABLE算法或者是UNION查询中的视图；
3、ORDER BY和GROUP BY的子句不一样时；
4、表连接中，ORDER BY的列不是驱动表中的；
5、DISTINCT查询并且加上ORDER BY时；
6、SQL中用到SQL_SMALL_RESULT选项时；
7、FROM中的子查询；
8、子查询或者semi-join时创建的表；

EXPLAIN 查看执行计划结果的 Extra 列中，如果包含 Using Temporary 就表示会用到临时表。

当然了，如果临时表中需要存储的数据量超过了上限（ tmp-table-size 或max-heap-table-size 中取其大者），这时候就需要生成基于磁盘的临时表了。 Continue reading →

[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键

Posted on by

我们先了解下InnoDB引擎表的一些关键特征：

  • InnoDB引擎表是基于B+树的索引组织表(IOT)；
  • 每个表都需要有一个聚集索引(clustered index)；
  • 所有的行记录都存储在B+树的叶子节点(leaf pages of the tree)；
  • 基于聚集索引的增、删、改、查的效率相对是最高的；
  • 如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择其作为聚集索引；
  • 如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引；
  • 如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。

综上总结，如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话，这时候存取效率是最高的，也就是下面这几种情况的存取效率最高：

  • 使用自增列(INT/BIGINT类型)做主键，这时候写入顺序是自增的，和B+数叶子节点分裂顺序一致；
  • 该表不指定自增列做主键，同时也没有可以被选为主键的唯一索引(上面的条件)，这时候InnoDB会选择内置的ROWID作为主键，写入顺序和ROWID增长顺序一致；
  • 除此以外，如果一个InnoDB表没有显式主键，但有可以被选择为主键的唯一索引，且该唯一索引可能不是递增关系时(例如字符串、UUID、多字段联合唯一索引的情况)，该表的存取效率就会特别差。

实际情况是如何呢？经过简单TPCC基准测试，修改为使用自增列作为主键与原始表结构分别进行TPCC测试，前者的TpmC结果比后者高9%倍，足见使用自增列做InnoDB表主键的明显好处，其他更多不同场景下使用自增列的性能提升可以自行对比测试下。 Continue reading →