《高性能MySQL》读书笔记（二）

#锁粒度
加锁也需要消耗资源，锁的各种操作，包括获得锁、检查锁是否已经解除、释放锁等，都会增加系统的开销。

#ACID
原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）。

#隔离级别
READ UNCOMMITTED（未提交读）
READ COMMITTED（提交读）
REPEATABLE READ（可重复读）
SERIALIZABLE（可串行化）

#死锁
死锁是指两个或多个事务对已获得的资源保持不放，并请求锁定对方占用的资源，从而导致恶性循环的现象。
避免死锁的方案：对资源的获取顺序要保持一致，这样可以尽量避免已占用资源的情况下才发现下一个要占用的资源已经被别的事务占用了。
死锁的处理：要有回滚后的处理机制，innoDB目前处理死锁的方法是，将持有最少行级排他锁的事务进行回滚。回滚后最好有补偿方案（比如定时任务重新发起请求）。

#事务日志
1.使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把修改行为记录到持久在硬盘上的事务日志中。
2.事务日志采用的是追加的方式，因此写日志的操作时磁盘上一小块区域内的顺序I/O。
3.事务日志持久以后，内存中被修改的数据在后台可以慢慢地刷回到磁盘。

#显式和隐式锁定
1.事务中的加锁是隐式的，在事务执行过程中，随时都可以执行锁定，所只有在执行COMMIT或者ROLLBACK的时候才会释放，并且所有的锁是在同一时刻被释放。
2.InnoDB也支持显式锁定，如下：
SELECT ... LOCK IN SHARE MODE;
SELECT ... FOR UPDATE;
这些显式锁定经常被滥用，实际上应当尽量避免使用。

#服务器性能剖析
#使用USER_STATISTICS表
SHOW TABLES FROM INFORMATION_SCHEMA LIKE '%_STATISTICS';
1.可以查找用得最多或最少的表和索引，通过读取次数或者更新次数，或者两者一起排序；
2.可以查找出从未使用的索引，可以考虑删除之；
3.可以看看复制用户的CONNECTED_TIME和BUSY_TIME，以确认复制是否会很难跟上主库的进度。

#索引
B+树索引适用于全键值、键值范围或键前缀查找。
1.全值匹配；
2.匹配最左前缀；
3.匹配列前缀；
4.匹配范围值；
5.精确匹配某一列并范围匹配另外一列；
6.只访问索引的查询

#索引类型
1.B-树索引
2.哈希索引：只有精确匹配索引所有列的查询才有效（Memory引擎）
3.空间数据索引（R-Tree）：MyISAM表支持空间索引，可以用作地理数据存储。
4.全文索引：是一种特殊类型的索引，它查找的是文本中的关键词，而不是直接比较索引中的值。全文索引适用于MATCH AGAINST操作，而不是普通的WHERE条件操作。

#索引的优点
1.索引大大减少了服务器需要扫描的数据量；
2.索引可以帮助服务器避免排序和临时表；
3.索引可以将随机I/O变为顺序I/O。

#索引是最好的解决方案吗？
索引并不总是最好的工具。只有当索引帮助存储引擎快速查找到记录带来的好处大于其带来的额外工作时，索引才是有效的。
非常小的表时全表扫描更高效。
对于中到大型的表，索引就非常有效。
对于特大型的表，建立和使用索引的代价将随之增长（这时要考虑分区或分表）。

#高性能的索引策略
1.独立的列，“独立的列”是指索引列不能是表达式的一部分，也不能是函数的参数。
2.前缀索引和索引选择性；
3.多列索引；
如果在EXPLAIN中看到有索引合并，应该好好检查一下查询和表的结构，看是不是已经是最优的（是否应该建一个多列索引）。也可以通过参数optimizer_switch来关闭索引合并功能，
也可以使用IGNORE_INDEX提示让优化器忽略掉某些索引。

#二级索引中存储的是主键值，而不是物理地址，有什么好处
这样的策略减少了当出现行移动或者数据页分裂时二级索引的维护工作。
使用主键值当作指针会让二级索引占用更多的空间，换来的好处是，InnoDB在移动行时无须更新二级索引中的这个“指针”。

#不连续的主键字段带来什么问题
1.频繁的页分裂
2.空间碎片

#优化数据访问
1.是否向服务器请求了不需要的数据
查询不需要的记录（解决办法是用limit）；
多表关联时返回全部列（要指定需要那些表的那些字段）；
总是取出全部列；
重复查询相同的数据。
2.MySQL是否在扫描额外的记录
响应时间；
扫描的行数；
返回的行数。

#重构查询的方式
1.一个复杂查询还是多个简单查询；
2.切分查询；
3.分解关联查询。

#查询执行路径