mysql数据库优化理论

Analyze Table

更新要扫描的表的索引键分布
MySQL 的Optimizer（优化元件）在优化SQL语句时，首先需要收集一些相关信息，其中就包括表的cardinality（可以翻译为“散列程度”），它表示某个索引对应的列包含多少个不同的值——如果cardinality大大少于数据的实际散列程度，那么索引就基本失效了。
我们可以使用SHOW INDEX语句来查看索引的散列程度：

SHOW INDEX FROM PLAYERS;

TABLE   KEY_NAME COLUMN_NAME CARDINALITY
------- -------- ----------- -----------
PLAYERS PRIMARY  PLAYERNO     14

因为此时PLAYER表中不同的PLAYERNO数量远远多于14，索引基本失效。
下面我们通过Analyze Table语句来修复索引：

ANALYZE TABLE PLAYERS;
SHOW INDEX FROM PLAYERS;
结果是：
TABLE   KEY_NAME COLUMN_NAME CARDINALITY
------- -------- ----------- -----------
PLAYERS PRIMARY  PLAYERNO    1000

此时索引已经修复，查询效率大大提高。

需要注意的是，如果开启了binlog，那么Analyze Table的结果也会写入binlog，我们可以在analyze和table之间添加关键字local取消写入。

Checksum Table

数据在传输时，可能会发生变化，也有可能因为其它原因损坏，为了保证数据的一致，我们可以计算checksum（校验值）。
使用MyISAM引擎的表会把checksum存储起来，称为live checksum，当数据发生变化时，checksum会相应变化。
在执行Checksum Table时，可以在最后指定选项qiuck或是extended；quick表示返回存储的checksum值，而extended会重新计算checksum，如果没有指定选项，则默认使用extended。

Optimize Table

经常更新数据的磁盘需要整理碎片，数据库也是这样，Optimize Table语句对MyISAM和InnoDB类型的表都有效。
如果表经常更新，就应当定期运行Optimize Table语句，保证效率。
与Analyze Table一样，Optimize Table也可以使用local来取消写入binlog。

Check Table

数据库经常可能遇到错误，譬如数据写入磁盘时发生错误，或是索引没有同步更新，或是数据库未关闭MySQL就停止了。
遇到这些情况，数据就可能发生错误：
Incorrect key file for table: ' '. Try to repair it.
此时，我们可以使用Check Table语句来检查表及其对应的索引。
譬如我们运行
CHECK TABLE PLAYERS;

结果是
TABLE          OP    MSG_TYPE MSG_TEXT
-------------- ----- -------- --------
TENNIS.PLAYERS check status   OK

MySQL会保存表最近一次检查的时间，每次运行check table都会存储这些信息：

 

执行
SELECT    TABLE_NAME, CHECK_TIME
FROM      INFORMATION_SCHEMA.TABLES
WHERE     TABLE_NAME = 'PLAYERS'
AND       TABLE_SCHEMA = 'TENNIS';  /*TENNIS是数据库名*/

结果是

TABLE_NAME   CHECK_TIME
----------   -------------------
PLAYERS      2006-08-21 16:44:25

Check Table还可以指定其它选项：
UPGRADE：用来测试在更早版本的MySQL中建立的表是否与当前版本兼容。
QUICK：速度最快的选项，在检查各列的数据时，不会检查链接（link）的正确与否，如果没有遇到什么问题，可以使用这个选项。
FAST：只检查表是否正常关闭，如果在系统掉电之后没有遇到严重问题，可以使用这个选项。
CHANGED：只检查上次检查时间之后更新的数据。
MEDIUM：默认的选项，会检查索引文件和数据文件之间的链接正确性。
EXTENDED：最慢的选项，会进行全面的检查。

 

Innodb引擎概述

Innodb引擎提供了对数据库ACID事务的支持，并且实现了SQL标准的四种隔离级别。该引擎还提供了行级锁和外键约束，它的设计目标是处理大容量数据库系统，它本身其实就是基于MySQL后台的完整数据库系统，MySQL运行时Innodb会在内存中建立缓冲池，用于缓冲数据和索引。但是该引擎不支持FULLTEXT类型的索引，而且它没有保存表的行数，当SELECT COUNT(*) FROM TABLE时需要扫描全表。当需要使用数据库事务时，该引擎当然是首选。由于锁的粒度更小，写操作不会锁定全表，所以在并发较高时，使用Innodb引擎会提升效率。但是使用行级锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表。

MyISAM引擎概述

MyISAM是MySQL默认的引擎，但是它没有提供对数据库事务的支持，也不支持行级锁和外键，因此当INSERT(插入)或UPDATE(更新)数据时即写操作需要锁定整个表，效率便会低一些。不过和Innodb不同，MyISAM中存储了表的行数，于是SELECT COUNT(*) FROM TABLE时只需要直接读取已经保存好的值而不需要进行全表扫描。如果表的读操作远远多于写操作且不需要数据库事务的支持，那么MyISAM也是很好的选择。

简单介绍区别

1、MyISAM是非事务安全的，而InnoDB是事务安全的

2、MyISAM锁的粒度是表级的，而InnoDB支持行级锁

3、MyISAM支持全文类型索引，而InnoDB不支持全文索引

4、MyISAM相对简单，效率上要优于InnoDB，小型应用可以考虑使用MyISAM

5、MyISAM表保存成文件形式，跨平台使用更加方便

应用场景

1、MyISAM管理非事务表，提供高速存储和检索以及全文搜索能力，如果再应用中执行大量select操作，应该选择MyISAM

2、InnoDB用于事务处理，具有ACID事务支持等特性，如果在应用中执行大量insert和update操作，应该选择InnoDB