一天一点点

-- 何登成技术博客
20151110
主题：mysql聚簇索引--只针对innodb
（来自MySQL reference manual 14.2.10.1）
=============================================
Every InnoDB table has a special index called the clustered index where the data for the rows is stored. Typically, the clustered index is synonymous with the primary key To get the best performance from queries, inserts, and other database operations, you must understand how InnoDB uses the clustered index to optimize the most common lookup and DML operations for each table.
innodb表的主键索引是聚簇索引，数据与索引存储在一起。
1.If you define a PRIMARY KEY on your table, InnoDB uses it as the clustered index.
如果表有主键，innodb将其作为聚簇索引。
2.If you do not define a PRIMARY KEY for your table, MySQL picks the first UNIQUE index that has only NOT NULL columns as the primary key and InnoDB uses it as the clustered index.
如果表没有主键，mysql会将具有非空列的唯一索引作为聚簇索引。
3.If the table has no PRIMARY KEY or suitable UNIQUE index, InnoDB internally generates a hidden clustered index on a synthetic column containing row ID values. The rows are ordered by the ID that InnoDB assigns to the rows in such a table. The row ID is a 6-byte field that increases monotonically as new rows are inserted. Thus, the rows ordered by the row ID are physically in insertion order.
如果没有主键或者合适的唯一索引，innodb也会在内部产生一个隐藏的聚簇索引列，包含的自增的rowid是6字节的。

聚簇索引如何加速查询
Accessing a row through the clustered index is fast because the row data is on the same page where the index search leads. If a table is large, the clustered index architecture often saves a disk I/O operation when compared to storage organizations that store row data using a different page from the index record. (For example, MyISAM uses one file for data rows and another for index records.)
通过聚簇索引访问数据之所以很快，是因为索引及被索引的数据存在于同一页。相对于其他存储引擎而言，节省了一次磁盘io。

聚簇索引与二级索引的关系
All indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index.
所有的非聚簇索引叫二级索引，二级索引中都包含行的主键列。

If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key.

如果主键列很长，那二级索引就会占用大量的空间，所以主键列越短越好。

主题：mvcc 并发控制中的快照读与当前读
（来自何登成的技术博客）
=============================================
快照读，读取的是记录的可见版本 (有可能是历史版本)，不用加锁。当前读，读取的是记录的最新版本，并且，当前读返回的记录，都会加上锁，保证其他事务不会再并发修改这条记录。
1.快照读
简单select操作为快照读，不加锁
2.当前读
增删改操作都是当前读，加X锁，逐行操作；
select * from table where ? lock in share mode; -- 加S锁的当前读
select * from table where ? for update;  -- 加X锁的当前读

20151111
主题：两阶段锁机制
（来自何登成博客）
=============================================
两阶段锁机制
1.加锁阶段--只加锁，不解锁；
2.解锁阶段--只解锁，不加锁。

主题：事务隔离级别
（来自何登成博客）
=============================================
针对当前读，提交读保证对读取到的记录加锁，存在幻读；
针对当前读，重复读在加记录锁的同时，还对满足条件的记录加gap锁；
串行读从基于mvcc的并发控制退化为基于锁的并发控制，不区别快照读和当前读，所有的
读操作均为当前读，读加读锁（S），写加写锁（X），读写冲突；

20151112
主题：一条简单SQL的加锁分析
（来自何登成博客）
=============================================


20151113
主题：一条复制SQL的加锁分析
（来自何登成博客）
=============================================

结论：在Repeatable Read隔离级别下，针对一个复杂的SQL，首先需要提取其where条件。Index Key确定的范围，需要加上GAP锁；Index Filter过滤条件，视MySQL版本是否支持ICP，若支持ICP，则不满足Index Filter的记录，不加X锁，否则需要X锁；Table Filter过滤条件，无论是否满足，都需要加X锁。

主题：死锁原因分析
（来自何登成博客）
=============================================

结论：死锁的发生与否，并不在于事务中有多少条SQL语句，死锁的关键在于：两个(或以上)的Session加锁的顺序不一致。而使用本文上面提到的，分析MySQL每条SQL语句的加锁规则，分析出每条语句的加锁顺序，然后检查多个并发SQL间是否存在以相反的顺序加锁的情况，就可以分析出各种潜在的死锁情况，也可以分析出线上死锁发生的原因。

20151116
主题：mysql reference tutorial
（来自何登成博客）
=============================================
3.1 Connecting to and Disconnecting from the Server
3.2 entering quries
1.查询执行时间不是精确的cpu时间；
2.在同一行能输入多条语句，语句间用分号分开；
3.一条语句也能写成多行；
4.\c取消命令执行；