高性能MySQL

1、AUTO_INCREMENT自增字段以2000开头，方便关联表修单关联，另外添加unsigend，避免负整数浪费:

有符号值：-128 到127（- 27 到27 - 1）

无符号值：0到255（0 到28 - 1） 1个字节

对于Innodb来说，UUID和自增ID做主键的优缺点

1）UUID主键，安全一些，不能猜到其他主键的值。缺点：占空间、插入慢

2）自增ID做主键，占空间小，插入块。

mysql的聚簇索引和数据是在同一个B+tree里，并且是按照顺序存储的，自增ID的话，就可以顺序存储到物理硬盘上，UUID就不能做到。

采用什么作为主键，还是根据实际需求做平衡。

2、mysql中不推荐使用null作为列的默认值

列中使用NULL值容易引发不受控制的事情发生,有时候还会严重托慢系统的性能.

例如:

null value will not be estimated in aggregate function() which may cause inaccurate results.
对含有NULL值的列进行统计计算,eg. count(),max(),min(),结果并不符合我们的期望值.
null value will influence the behavior of the operations such as “distinct”,“group by”,“order by” which causes wrong sort.
干扰排序，分组,去重结果.
null value needs ifnull() function to do judgement which makes the program code more complex.
有的时候为了消除NULL带来的技术债务,我们需要在SQL中使用IFNULL()来确保结果可控,但是这使程序变得复杂.
null value needs a extra 1 byte to store the null information in the rows.
NULL值并是占用原有的字段空间存储,而是额外申请一个字节去标注,这个字段添加了NULL约束.(就像额外的标志位一样)
As these above drawbacks,it’s not recommended to define columns with default null.
We recommand to define “not null” on all columns and use zero number & vacant string to substitute relevant data type of null.
根据以上缺点,我们并不推荐在列中设置NULL作为列的默认值,你可以使用NOT NULL消除默认设置,使用0或者''空字符串来代替NULL.

3、TIMESTAMP只DATETIME一半的存储空间，并且会根据时区变化，具有特殊的自动更新能力。但TIMESTAMP允许的时间范围小，1970-2038年。

4、使用简单的数据类型，需要更少的CUP周期，例如使用整型比字符型操作代价低。另外就是使用MySQL自带的类型存储数据，比如不用字符串存储时间和IP。

5、CHAR类型是定长的，存储时会截调后面的空格，然后根据CHAR长度补全空格，以方便比较，所以CHAR很适合存储很短的字符串，或者长度很接近的字符串，比如密码的MD5值。因为是定长的，CHAR比较适合存储经常更新的数据，这样不易产生碎片。对于很短的列，CHAR也比VARCHAR有优势，CHAR(1)只需要1个字节，二VARCHAR(1)需要2个字节，因为需要额外1个字节记录长度。

6、聚簇索引和非聚簇索引

1）聚簇索引并不是一种单独的索引类型，而是一种数据存储方式。InnoDB的聚簇索引实际上在同一个结构中保存了B-Tree的索引和数据。

主键和聚簇索引：InnoDB引擎中，表可以没有主键，但必须有聚簇索引，当有主键时，主键就是聚簇索引，没有主键时，MySQL会选择一个唯一的非空索引代替，如果没有这样的索引，就会隐士定义一个主键作为聚簇索引。

如果根据聚簇索引查询，因为数据和索引都保存在同一个B-Tree中，所以要比非聚簇索引查询快。

2）非聚簇索引：联合索引、唯一索引都属于非聚簇索引，也称辅助索引、二级索引。

二级索引的叶子节点，包含了主键列，所以访问时需要两次索引查找，而不是一次。

7、覆盖索引，如果一个索引包含（或者说覆盖）所需要查询的字段值，我们称之为覆盖索引。覆盖索引代表要查询的数据已在叶子节点，查询时不需要回表，减少IO。

MySQL只能使用B-Tree索引做覆盖索引。

8、优化查询。拆分查询，将一个复杂查询拆分成多个简单查询。在传统实现中，总是强调需要在数据库层完成尽可能多的工作，认为网络通信、查询解析和优化是代价很高的事。但这并不适合MySQL，MySQL从设计上来说断开和链接都是轻量级的，小的查询很高效，加上现在网络速度比之前要快不少。所以拆分成多个查询有时更合适，简单查询可只返回需要的字段。

但如果查询并不复杂，非要拆分成多个查询，也不是明智的，具体还要具体场景具体分析。