我们知道在MySQL中存在表级锁、页级锁和行级锁，其中MySQL默认实现了表级锁定。其它锁机制在不同的存储引擎中实现，这也是MySQL特点之一：针对特定的应用场景可以使用当前合适的存储引擎。先不论各种存储引擎和锁机制的优劣，这里只是说说他们各自的特点和实现。

MyISAM存储引擎作为曾经的默认存储引擎，其使用的锁机制是MySQL提供的默认表级锁定。虽然它没有实现自己的锁机制，但是在默认表级锁的基础上，增加了并发插入的特性。并发插入与系统参数concurrent_insert相关，concurrent_insert有三个值：

• concurrent_insert=0 关闭并发写入
• concurrent_insert=1 (默认)在没有空数据块的MyISAM表中启用并行插入
• concurrent_insert=2 为所有MyISAM表启用并行插入。如果表有空记录或正被另一线程使用，新行将插入到表的最后。如果表未使用，MySQL将进行普通读锁定并将新行插入空记录。

此参数与MyISAM存储引擎的数据存储方式相关：常规情况下，MyISAM的新数据都会被附加到数据文件的结尾，当做了一些DELETE操作之后，数据文件就不再是连续的，形象一点来说，就是数据文件里出现了很多hole，此时再插入新数据时，按缺省设置会先看这些hole的大小是否可以容纳下新数据，如果可以，则直接把新数据保存到hole里，反之，则把新数据保存到数据文件的结尾。之所以这样做是为了减少数据文件的大小，降低文件碎片的产生。

如果我们使用concurrent_insert=2（通常也推荐这样做），这样会产生较多的文件碎片，为此，我们需要在设置这个参数值的同时，定期对数据表进行OPTIMIZE TABLE操作。此操作可以去除删除操作后留下的数据文件碎片，减小文件尺寸，加快未来的读写操作。但是，在OPTIMIZE TABLE运行过程中，MySQL会锁表。

MySQL的表锁有两种模式：表共享读锁（Table Read Lock）和表独占写锁（Table Write Lock）。共享锁和独占锁在锁机制中是一种非常普通的实现方式。 MyISAM在执行查询语句前，会自动给涉及的所有表加读锁，在执行更新操作（DDL）前，会自动给相关的表加写锁。 MySQL的读写锁（mysys/thr_lock.c）是通过4个队列来维护的，他们分别是：

• 当前读锁队列（lock->read）： 存储当前持有读锁所有线程相关信息，按获取锁的时间排序
• 读锁等待队列（lock->read_wait）：存储正在等待读锁锁定资源的线程相关信息
• 当前写锁队列（lock->write）：存储当前持有写锁所有线程相关信息，按获取锁的时间排序
• 写锁等待队列（lock->write_wait）：存储正在等待写锁锁定资源的线程相关信息

对于读锁，当请求的资源没有加写锁或在写锁等待队列中没有更高优先级的写锁定在等待。读锁是共享锁，不会阻塞其他进程对同一资源的读请求，但会阻塞对同一资源的写请求。只有当读锁释放后，才会执行其它进程的写操作。

对于写锁，当请求的资源在当前写锁队列、写锁等待队列或当前读锁队列，进入等待写锁队列；写锁会阻塞其他进程对同一资源的读和写操作，只有当写锁释放后，才会执行其它进程的读写操作。

表锁是MySQL数据库中加锁粒度最大的一种锁，除此之外，MySQL还有页级锁和行锁。表锁的执行开销小，加锁速度快，不会出现死锁，但是其加锁的粒度大，发生锁冲突的概率非常高，从而导致并发度低。可以考虑使用主从结构解决并发度低的问题。

参考资料

http://www.zhaokunyao.com/archives/206

http://dev.mysql.com/doc/refman/5.1/zh/database-administration.html

《MySQL性能调优与架构设计》 – 简朝阳

由于某个临时需求，需要给在线MySQL的某个超过千万的表增加一个字段。此表在设计之时完全按照需求实现，并没有多余的保留字段。

我们知道在MySQL中如果要执行ALTER TABLE操作，MySQL会通过制作原来表的一个临时副本来工作。对于表结构的修改在副本上施行，然后将新表替换原始表，此时会产生锁表，用户可以从原始表读取数据，而用户的更新和写入操作都会被lock，待新表准备好后写入新表。
这对于在线的数据量较大的表来说是绝对无法容忍的，并且由于这种在线操作时间会很长，此时如果show processlist，会发现有若干的MySQL进程处于lock状态，当这种进程太多超过单台服务器允许的MySQL进程数，其它进程可能会被拒绝连接。

有哪些方案可以处理这个问题呢？

方案1、直接ALTER TABLE
这个方案只能说这仅仅是一种方案，在某些非实时在线或数据量较小时有较好的表现。

方案２、模拟数据库修改表结构的操作，在非数据库层实现整个过程。

1. 实现业务中对于数据的读写分离
2. 创建一个已经按需求修改好结构的新表
3. 修改业务逻辑，将读操作指向旧表，将写操作指向新表。如果读旧表没有，再读新表，并将旧的数据写入到新表，当然这一步写入操作我们可以不用，我们可以在后台做一个定时任务将旧数据同步到新表。

这种方案有一个较大的缺点，需要业务逻辑层配合实现数据的迁移，对于业务逻辑有修改，并且如果有多台机器的话，需要一台一台的修改，较费时间，但是对于MySQL的两种主要存储引擎都适用。

方案３、facebook online schema change
facebook的OSC在整体流程上与方案2没有较大的区别，只是它在这里引入了触发器，从而不需要修改业务逻辑，在数据库层就实现了新数据的两个表的同步问题。其大概步骤如下：

1. 按需求创建新表
2. 针对原始表创建触发器
3. 对于原始表的更新操作都会被触发器更新到新表中
4. 把原始表中的数据复制到新表中
5. 将新表替换旧表

fb的osc方案从数据库层解决了方案2的问题，但是它仅支持InnoDB存储引擎。

方案４、换一个思路，保留字段。
假设一切可以从头再来，我们也许可以加多一些冗余字段，各个类型都加一些，备用。只是，回不去了！

方案5、再换一个思路，增加扩展表。
我们不在原有的表的基础上修改了，以增加扩展表的方式，将新字段的数据写入到扩展表中，修改业务逻辑，这些字段从新表中读取。
志强同学说这是典型的维表结构设计。
暂时解决了问题，如果这些字段后续使用频率高的话，可能会有对后期维护或业务有一定的影响。

后记
基于现有的需求，只是需要记录新的字段，所以采用了扩展表的方案。

1
2
3
4
5

 
CREATE PROCEDURE test()
BEGIN
    SELECT 'Hello Word!';                                                               
END

在phpmyadmin及客户端都报错，在phpmyadmin中显示：#1064 – You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” at line 3

显然，程序在第一个分号后面出错了
原因不明，遂google之，找到如下地址：http://www.cnblogs.com/hsqzzzl/archive/2008/02/21/1076646.html
文章作者有说：分隔符是通知MySQL客户端已经输入完成的符号。一直都是用“;”，但是在存储过程中不行，因为存储过程中很多语句都需要用到分号
于是得到如下所示代码

1
2
3
4
5
6

DELIMITER ||
CREATE PROCEDURE test()
BEGIN
    SELECT 'Hello Word!';                              
END ||
DELIMITER ;

如果不想使用DELIMITER，在phpmyadmin中执行命令时，在Delimiter文本框中填写||

另在百度百科中有说明：http://baike.baidu.com/view/3068266.htm
MySQL中delimit命令。
　　这个命令与存储过程没什么关系。
　　其实就是告诉mysql解释器，该段命令是否已经结束了，mysql是否可以执行了。
　　即改变输入结束符。
　　默认情况下，delimiter是分号“;”。
　　在命令行客户端中，如果有一行命令以分号结束，
　　那么回车后，mysql将会执行该命令。
　　但有时候，不希望MySQL这么做。因为可能输入较多的语句，且语句中包含有分号。
　　默认情况下，不可能等到用户把这些语句全部输入完之后，再执行整段语句。
　　因为mysql一遇到分号，它就要自动执行。
　　这种情况下，就可以使用delimiter，把delimiter后面换成其它符号，如//或$$。
　　此时，delimiter作用就是对整个小段语句做一个简单的封装。
　　此命令多用在定义子程序，触发程序等musql自己内嵌小程序中。

此时，连接线程会调用安全管理模块，进行授权检查，验证用户访问的合法性（用户是否有权访问数据库服务器，用户密码是否正确等）
然后，连接线程开始处理客户端请求所发送过来的命令（或者Query）
对于命令，不需要调用Parse就可以直接执行
对于Query，需要进行Query解析和转发模块的解析，在Query解析器进行分析，如果是一个SELECT类型的Query，则调用查询缓存（Query Cache），检查是否存在相同的查询语句，如果存在则直接将cache中的数据返回，如果不存在或者不是SELECT类型的Query，则将此Query返回解析器。在此时的解析器中，如果是SELECT类型，则它会将控制权交给查询优化器，如果是DML或DDL语句，则会交给表变更管理模块，如果是一些更新统计信息，检测，修复和整理类的Query，则会交给表变更管理模块
这些模块在收到Query解析与分发模块分发过来的请求后，首先会通过访问控制模块检查连接用户是否有访问目标表和目标字段的权限，如果有相关权限，就会调用表管理模块请求相应的表，并获取相应的锁。
在打开表后，根据表的相关meta信息，判断表的存储引擎类型和相关信息。
根据表的存储引擎类型，提交请求给存储引擎接口，调用对应的存储引擎实现模块进行处理。

以上只是正常的流程，在此过程中还有处理失败的返回，验证失败的返回等等。如果MySQL打开了bin-log选项并且操作过程中数据发生的变化，那么相应的模块在处理的过程中会调用日志处理模块，将相应的变更语句以更新事件的形式记录到相关参数的二进制日志文件。

以上内容摘抄自《MySQL性能调优与架构设计》

以上所示的版本是指开始支持的版本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

CREATE TABLE `ticket_reply` (
  `reply_id` INT(11) NOT NULL AUTO_INCREMENT,
  `ticket_id` INT(11) NOT NULL,
  `reply_created` datetime DEFAULT NULL,
  `reply_content` text,
  PRIMARY KEY  (`reply_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
-- ----------------------------
-- Records 
-- ----------------------------
INSERT INTO `ticket_reply` VALUES ('1', '2', '2009-11-04 20:17:59', '11111');
INSERT INTO `ticket_reply` VALUES ('2', '2', '2009-11-04 20:22:09', '22222');
INSERT INTO `ticket_reply` VALUES ('3', '1', '2009-11-04 20:22:19', '33333');
INSERT INTO `ticket_reply` VALUES ('4', '3', '2009-11-04 20:22:28', '4444');
INSERT INTO `ticket_reply` VALUES ('5', '4', '2009-11-04 20:22:38', '5555');
INSERT INTO `ticket_reply` VALUES ('6', '1', '2009-11-04 20:22:49', '32');
INSERT INTO `ticket_reply` VALUES ('7', '1', '2009-11-04 20:23:18', '11');
INSERT INTO `ticket_reply` VALUES ('8', '1', '2009-11-04 20:23:26', '43');
INSERT INTO `ticket_reply` VALUES ('9', '2', '2009-11-04 20:23:41', '3');
INSERT INTO `ticket_reply` VALUES ('10', '3', '2009-11-04 20:23:50', '1');
INSERT INTO `ticket_reply` VALUES ('11', '3', '2009-11-04 20:24:02', '11');
INSERT INTO `ticket_reply` VALUES ('12', '4', '2009-11-04 20:24:12', 'f');
INSERT INTO `ticket_reply` VALUES ('13', '4', '2009-11-04 20:24:24', 'a');

【问题一】

在在In/all/any/sime等子查询里使用limit时会报错：
如下所示SQL
SELECT * FROM `ticket_reply` WHERE reply_id IN (SELECT reply_id * FROM `ticket_reply` LIMIT 3);
报错如下：
#1235 – This version of MySQL doesn’t yet support ‘LIMIT & IN/ALL/ANY/SOME subquery’

解决方案，添加一层查询，
SELECT * FROM `ticket_reply` WHERE reply_id IN (SELECT reply_id FROM (SELECT * FROM `ticket_reply` LIMIT 3) tb )
如果不加别名，则会显示
#1248 – Every derived table must have its own alias

【问题二】
mysql中分组后取各分组的最新的两组数据

1
2
3
4
5
6
7
8
9

SELECT s1. * 
FROM ticket_reply AS s1
WHERE (
SELECT COUNT( 1 ) 
FROM ticket_reply AS s2
WHERE s2.reply_created >= s1.reply_created
AND s2.ticket_id = s1.ticket_id
) <= 2
ORDER BY ticket_id, reply_created DESC

【问题三】
取每个帖子的最新回复

1
2
3
4
5
6
7
8

SELECT * 
FROM (
SELECT * 
FROM ticket_reply
ORDER BY reply_created DESC
) newtb
GROUP BY ticket_id
ORDER BY reply_created DESC