㈠ 如何用mysql表模拟队列
通常大家都会使用redis作为应用的任务队列表，redis的List结构，在一段进行任务的插入，在另一端进行任务的提取。
任务的插入
$redis->lPush("key:task:list",$task);
任务的提取
$tasks = $redis->RPop("key:task:list",0,-1);
可是大家想，如何使用mysql来实现一个队列表呢？
映入大家脑海的一个典型的模式是一个表包含多种类型的记录：未处理记录，已处理记录，正在处理记录等。一个或者多个消费者线程在表中查询未处理的记录，然后声称正在处理这个任务，处理完成之后，再讲记录更新为已处理状态。
这个典型的模式，存在两个问题；1：随着队列表越来越大，查找未处理记录的速度会越来越慢。2：频繁的加锁会让多个消费者线程增加竞争。
首先我们来创建一个表
create table unsent_emails{ id int not null primary key auto_increment, status enum("unsent","claimed","sent"),
owner int unsigned not null default 0,
ts timestamp, key (owner,status,ts)
};
该表的列owner用来存储当前正在处理这个记录的连接id，由函数 CONNECTION_ID()返回的连接id或者线程id。如果这个记录当前被没有被处理，则该值为0
我们在 owner status ts上面做了索引的处理，所以查找未处理洞枯的记录会很快。
通过我们会采用 select for update的方式来标记待处理的记录，方法如下
begin;select id from unsent_emails where owner = 0 and status = 'unsent'
limit 10 for update;-- result 10,20,33update unsent_emails set status = 'claimed',owner = CONNECTION_ID() where id in (10,20,33);
commit;
select的时候，使用了两个索引，应该会很快。问题出在select 和 update两个查询之间的间隙，这里的加锁会让其他相同的查询全部阻塞。
如果我们采用update then select的方式，那么效果就会更加高效，代码如下
set autocommit=1;commit;update unsent_emails set statue = 'claimed',owner = CONNECTION_ID() where owner = 0 and status = 'unsent'
limit 10;set autocommit=0;select id from unsent_emails where owner = CONNECTION_ID() and status = 'claimed';
根本无需使用select去查蔽配找哪些记录还没有处理。客户端协议会告诉你更新了几条记录，就可以知道这次需要处理多少条记录。
这样是不是解决了上面的第二个问题，select for update的模式的加锁会增加多个消费队列的竞争问题。
其实所有的select for update 都可以替换为 update then select模式。
问题还没有结束，还有一种情况需要处理，就是比如正在处理任务的进程异常退出了，那么对应的进程正在处理的任务也就变为僵尸任务了。如何避免这种情况的发生呢？
所以我们还是需要一个新的定时器或者线程来定时检测纳并洞并且update，将那些僵尸任务的记录更新到原始状态，就可以了。
僵尸任务的定义必须符合两点，1：任务被搁置了很久，比如十分钟，而通常一个任务只需要10秒就可以处理完；2：任务的owner(线程id或者连接id)已经不存在，只需要执行show processlist就可以获取当前正在工作的线程id了。代码如下
update unsent_emails set owner = 0,status = 'unsent'
where owner not in (10,20,33,44) and status = 'claimed'
and ts < current_timestamp - interval 10 minute;
一个基于mysql构建的队列表就完成了。
当然，最好的办法就是将任务队列从数据库中迁移出来。redis真是一个很好的队列容器，当然也可以使用ssdb(基于leveldb，内存占用更少)。
㈡ 用sql语句，怎么解决mysql数据库死锁
MySQL死锁问题的相关知识是本文我们主要要介绍的内容，接下来我们就来一一介绍这部分内容，希望能够对您有所帮助。
1、MySQL常用存储引擎的锁机制
MyISAM和MEMORY采用表级锁(table-level locking)
BDB采用页面锁(page-level locking)或表级锁，默认为页面锁
InnoDB支持行级锁(row-level locking)和表级锁，默认为行级锁
2、各种锁特点
表级锁：开销小，加锁快;不会出现死锁;锁定粒度大，发生锁冲突的概率最高，并发度最低
行级锁：开销大，加锁慢;会出现死锁;锁定粒度最小，发生锁冲突的概率最低，并发度也最高
页面锁：开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间，并发度一般
3、各种锁的适用场景
表级锁更适合于以查询为主，只有少量按索引条件更新数据的应用，如Web应用
行级锁则更适合于有大量按索引条件并发更新数据，同时又有并发查询的应用，如一些在线事务处理系统
4、死锁
是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。
表级锁不会产生死锁。所以解决死锁主要还是针对于最常用的InnoDB。
5、死锁举例分析
在MySQL中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条sql语句操作了主键索引，MySQL就会锁定这条主键索引;如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。
在UPDATE、DELETE操作时，MySQL不仅锁定WHERE条件扫描过的所有索引记录，而且会锁定相邻的键值，即所谓的next-key locking。
例如，一个表db。tab_test，结构如下：
id：主键;
state：状态;
time：时间;
索引：idx_1(state，time)
出现死锁日志如下：
?***(1) TRANSACTION:
?TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OSthread id 278546 starting index read
?mysql tables in use 1, locked 1
?LOCK WAIT 3 lock struct(s), heap size 320
?MySQL thread id 83, query id 162348740 dcnet03 dcnet Searching rows for update
?update tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute) (任务1的sql语句)
?***(1) WAITING FOR THIS LOCK TO BE GRANTED: (任务1等待的索引记录)
?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833455 _mode X locks rec but not gap waiting
?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
?0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T&;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 8616e642e706870; asc xxx.com/;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc N$;;
?*** (2) TRANSACTION:
?TRANSACTION 0 677833454, ACTIVE 0 sec, process no 11397, OS thread id 344086 updating or deleting, thread declared inside InnoDB 499
?mysql tables in use 1, locked 1
?3 lock struct(s), heap size 320, undo log entries 1
?MySQL thread id 84, query id 162348739 dcnet03 dcnet Updating update tab_test set state=1067,time=now () where id in (9921180) (任务2的sql语句)
?*** (2) HOLDS THE LOCK(S): (任务2已获得的锁)
?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap
?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
?0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T&;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 8616e642e706870; asc uploadfire.com/hand.php;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc N$;;
?*** (2) WAITING FOR THIS LOCK TO BE GRANTED: (任务2等待的锁)
?RECORD LOCKS space id 0 page no 843102 n bits 600 index `idx_1` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap waiting
?Record lock, heap no 395 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
?0: len 8; hex 8000000000000425; asc %;; 1: len 8; hex 800012412c66d29c; asc A,f ;; 2: len 8; hex 800000000097629c; asc b ;;
?*** WE ROLL BACK TRANSACTION (1)
?(回滚了任务1，以解除死锁)
原因分析：
当“update tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute)”执行时，MySQL会使用idx_1索引，因此首先锁定相关的索引记录，因为idx_1是非主键索引，为执行该语句，MySQL还会锁定主键索引。
假设“update tab_test set state=1067,time=now () where id in (9921180)”几乎同时执行时，本语句首先锁定主键索引，由于需要更新state的值，所以还需要锁定idx_1的某些索引记录。
这样第一条语句锁定了idx_1的记录，等待主键索引，而第二条语句则锁定了主键索引记录，而等待idx_1的记录，这样死锁就产生了。
6、解决办法
拆分第一条sql，先查出符合条件的主键值，再按照主键更新记录：
?select id from tab_test where state=1061 and time < date_sub(now(), INTERVAL 30 minute);
?update tab_test state=1064,time=now() where id in(......);
㈢ mysql 分区和分表 哪个好
mysql 分区和分表好
一，什么是mysql分表，分区
什么是分表，从表面意思上看呢，就是把一张表分成N多个小表，具体请看mysql分表的3种方法
什么是分区，分区呢就是把一张表的数据分成N多个区块，这些区块可以在同一个磁盘上，也可以在不同的磁盘上
一，先说一下为什么要分表
当一张的数据达到几百万时，你查询一次所花的时间会变多，如果有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减小数据库的负担，缩短查询时间。
根据个人经验，mysql执行一个sql的过程如下：
1,接收到sql;2,把sql放到排队队列中 ;3,执行sql;4,返回执行结果。在这个执行过程中最花时间在什么地方呢？第一，是排队等待的时间，第二，sql的执行时间。其实这二个是一回事，等待的同时，肯定有sql在执行。所以我们要缩短sql的执行时间。
mysql中有一种机制是表锁定和行锁定，为什么要出现这种机制，是为了保证数据的完整性，我举个例子来说吧，如果有二个sql都要修改同一张表的同一条数据，这个时候怎么办呢，是不是二个sql都可以同时修改这条数据呢？很显然mysql对这种情况的处理是，一种是表锁定（myisam存储引擎），一个是行锁定（innodb存储引擎）。表锁定表示你们都不能对这张表进行操作，必须等我对表操作完才行。行锁定也一样，别的sql必须等我对这条数据操作完了，才能对这条数据进行操作。如果数据太多，一次执行的时间太长，等待的时间就越长，这也是我们为什么要分表的原因。
二，分表
1，做mysql集群，例如：利用mysql cluster ，mysql proxy，mysql replication，drdb等等
有人会问mysql集群，根分表有什么关系吗？虽然它不是实际意义上的分表，但是它启到了分表的作用，做集群的意义是什么呢？为一个数据库减轻负担，说白了就是减少sql排队队列中的sql的数量，举个例子：有10个sql请求，如果放在一个数据库服务器的排队队列中，他要等很长时间，如果把这10个sql请求，分配到5个数据库服务器的排队队列中，一个数据库服务器的队列中只有2个，这样等待时间是不是大大的缩短了呢？这已经很明显了。所以我把它列到了分表的范围以内，我做过一些mysql的集群：
linux mysql proxy 的安装，配置，以及读写分离
mysql replication 互为主从的安装及配置，以及数据同步
优点：扩展性好，没有多个分表后的复杂操作（php代码）
缺点：单个表的数据量还是没有变，一次操作所花的时间还是那么多，硬件开销大。
2，预先估计会出现大数据量并且访问频繁的表，将其分为若干个表
这种预估大差不差的，论坛里面发表帖子的表，时间长了这张表肯定很大，几十万，几百万都有可能。 聊天室里面信息表，几十个人在一起一聊一个晚上，时间长了，这张表的数据肯定很大。像这样的情况很多。所以这种能预估出来的大数据量表，我们就事先分出个N个表，这个N是多少，根据实际情况而定。以聊天信息表为例：
我事先建100个这样的表，message_00,message_01,message_02..........message_98,message_99.然后根据用户的ID来判断这个用户的聊天信息放到哪张表里面，你可以用hash的方式来获得，可以用求余的方式来获得，方法很多，各人想各人的吧。下面用hash的方法来获得表名：
查看复制打印?
<?php
function get_hash_table($table,$userid) {
$str = crc32($userid);
if($str<0){
$hash = "0".substr(abs($str), 0, 1);
}else{
$hash = substr($str, 0, 2);
}
return $table."_".$hash;
}
echo get_hash_table('message','user18991'); //结果为message_10
echo get_hash_table('message','user34523'); //结果为message_13
?>
说明一下，上面的这个方法，告诉我们user18991这个用户的消息都记录在message_10这张表里，user34523这个用户的消息都记录在message_13这张表里，读取的时候，只要从各自的表中读取就行了。
优点：避免一张表出现几百万条数据，缩短了一条sql的执行时间
缺点：当一种规则确定时，打破这条规则会很麻烦，上面的例子中我用的hash算法是crc32，如果我现在不想用这个算法了，改用md5后，会使同一个用户的消息被存储到不同的表中，这样数据乱套了。扩展性很差。
3，利用merge存储引擎来实现分表
我觉得这种方法比较适合，那些没有事先考虑，而已经出现了得，数据查询慢的情况。这个时候如果要把已有的大数据量表分开比较痛苦，最痛苦的事就是改代码，因为程序里面的sql语句已经写好了，现在一张表要分成几十张表，甚至上百张表，这样sql语句是不是要重写呢？举个例子，我很喜欢举子
mysql>show engines;的时候你会发现mrg_myisam其实就是merge。
查看复制打印?
mysql> CREATE TABLE IF NOT EXISTS `user1` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `name` varchar(50) DEFAULT NULL,
-> `sex` int(1) NOT NULL DEFAULT '0',
-> PRIMARY KEY (`id`)
-> ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
Query OK, 0 rows affected (0.05 sec)
mysql> CREATE TABLE IF NOT EXISTS `user2` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `name` varchar(50) DEFAULT NULL,
-> `sex` int(1) NOT NULL DEFAULT '0',
-> PRIMARY KEY (`id`)
-> ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
Query OK, 0 rows affected (0.01 sec)
mysql> INSERT INTO `user1` (`name`, `sex`) VALUES('张映', 0);
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO `user2` (`name`, `sex`) VALUES('tank', 1);
Query OK, 1 row affected (0.00 sec)
mysql> CREATE TABLE IF NOT EXISTS `alluser` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `name` varchar(50) DEFAULT NULL,
-> `sex` int(1) NOT NULL DEFAULT '0',
-> INDEX(id)
-> ) TYPE=MERGE UNION=(user1,user2) INSERT_METHOD=LAST AUTO_INCREMENT=1 ;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> select id,name,sex from alluser;
+----+--------+-----+
| id | name | sex |
+----+--------+-----+
| 1 | 张映 | 0 |
| 1 | tank | 1 |
+----+--------+-----+
2 rows in set (0.00 sec)
mysql> INSERT INTO `alluser` (`name`, `sex`) VALUES('tank2', 0);
Query OK, 1 row affected (0.00 sec)
mysql> select id,name,sex from user2
-> ;
+----+-------+-----+
| id | name | sex |
+----+-------+-----+
| 1 | tank | 1 |
| 2 | tank2 | 0 |
+----+-------+-----+
㈣ MySQL知识点总结
只要字段值还可以继续拆分，就不满足第一范式。
范式设计得越详细，对某些实际操作可能会更好，但并非都有好处，需要对项目的实际情况进行设定。
在满足第一范式的前提下，其他列都必须完全依赖于主键列。 如果出现不完全依赖，只可能发生在联合主键的情况下：
实际上，在这张订单表中，proct_name 只依赖于 proct_id ，customer_name 只依赖于 customer_id。也就是说，proct_name 和 customer_id 是没用关系的，customer_name 和 proct_id 也是没有关系的。
这就不满足第二范式：其他列都必须完全依赖于主键列！
拆分之后，myorder 表中的 proct_id 和 customer_id 完全依赖于 order_id 主键，而 proct 和 customer 表中的其他字段又完全依赖于主键。满足了第二范式的设计！
在满足第二范式的前提下，除了主键列之外，其他列之间不能有传递依赖关系。
表中的 customer_phone 有可能依赖于 order_id 、 customer_id 两列，也就不满足了第三范式的设计：其他列之间不能有传递依赖关系。
修改后就不存在其他列之间的传递依赖关系，其他列都只依赖于主键列，满足了第三范式的设计！
查询每门课的平均成绩。
查询 score 表中至少有 2 名学生选修，并以 3 开头的课程的平均分数。
分析表发现，至少有 2 名学生选修的课程是 3-105 、3-245 、6-166 ，以 3 开头的课程是 3-105 、3-245。也就是说，我们要查询所有 3-105 和 3-245 的 degree 平均分。
查询所有学生的 name，以及该学生在 score 表中对应的 c_no 和 degree 。
通过分析可以发现，只要把 score 表中的 s_no 字段值替换成 student 表中对应的 name 字段值就可以了，如何做呢？
查询所有学生的 no 、课程名称 ( course 表中的 name ) 和成绩 ( score 表中的 degree ) 列。
只有 score 关联学生的 no ，因此只要查询 score 表，就能找出所有和学生相关的 no 和 degree ：
然后查询 course 表：
只要把 score 表中的 c_no 替换成 course 表中对应的 name 字段值就可以了。
查询所有学生的 name 、课程名 ( course 表中的 name ) 和 degree 。
只有 score 表中关联学生的学号和课堂号，我们只要围绕着 score 这张表查询就好了。
只要把 s_no 和 c_no 替换成 student 和 srouse 表中对应的 name 字段值就好了。
首先把 s_no 替换成 student 表中的 name 字段：
再把 c_no 替换成 course 表中的 name 字段：
查询 95031 班学生每门课程的平均成绩。
在 score 表中根据 student 表的学生编号筛选出学生的课堂号和成绩：
这时只要将 c_no 分组一下就能得出 95031 班学生每门课的平均成绩：
查询在 3-105 课程中，所有成绩高于 109 号同学的记录。
首先筛选出课堂号为 3-105 ，在找出所有成绩高于 109 号同学的的行。
查询所有成绩高于 109 号同学的 3-105 课程成绩记录。
查询所有和 101 、108 号学生同年出生的 no 、name 、birthday 列。游御
查询 '张旭' 教师任课的学生成绩表。
首先找到教师编号悔中：
通过 sourse 表找到该神前岩教师课程号：
通过筛选出的课程号查询成绩表：
查询某选修课程多于5个同学的教师姓名。
首先在 teacher 表中，根据 no 字段来判断该教师的同一门课程是否有至少5名学员选修：
查看和教师编号有有关的表的信息：
我们已经找到和教师编号有关的字段就在 course 表中，但是还无法知道哪门课程至少有5名学生选修，所以还需要根据 score 表来查询：
根据筛选出来的课程号，找出在某课程中，拥有至少5名学员的教师编号：
在 teacher 表中，根据筛选出来的教师编号找到教师姓名：
查询 “计算机系” 课程的成绩表。
思路是，先找出 course 表中所有 计算机系 课程的编号，然后根据这个编号查询 score 表。
查询 计算机系 与 电子工程系 中的不同职称的教师。
查询课程 3-105 且成绩 至少 高于 3-245 的 score 表。
查询课程 3-105 且成绩高于 3-245 的 score 表。
查询某课程成绩比该课程平均成绩低的 score 表。
查询所有任课 ( 在 course 表里有课程 ) 教师的 name 和 department 。
查询 student 表中至少有 2 名男生的 class 。
查询 student 表中不姓 "王" 的同学记录。
查询 student 表中每个学生的姓名和年龄。
查询 student 表中最大和最小的 birthday 值。
以 class 和 birthday 从大到小的顺序查询 student 表。
查询 "男" 教师及其所上的课程。
查询最高分同学的 score 表。
查询和 "李军" 同性别的所有同学 name 。
查询和 "李军" 同性别且同班的同学 name 。
查询所有选修 "计算机导论" 课程的 "男" 同学成绩表。
需要的 "计算机导论" 和性别为 "男" 的编号可以在 course 和 student 表中找到。
建立一个 grade 表代表学生的成绩等级，并插入数据：
查询所有学生的 s_no 、c_no 和 grade 列。
思路是，使用区间 ( BETWEEN ) 查询，判断学生的成绩 ( degree ) 在 grade 表的 low 和 upp 之间。
准备用于测试连接查询的数据：
分析两张表发现，person 表并没有为 cardId 字段设置一个在 card 表中对应的 id 外键。如果设置了的话，person 中 cardId 字段值为 6 的行就插不进去，因为该 cardId 值在 card 表中并没有。
要查询这两张表中有关系的数据，可以使用 INNER JOIN ( 内连接 ) 将它们连接在一起。
完整显示左边的表 ( person ) ，右边的表如果符合条件就显示，不符合则补 NULL 。
完整显示右边的表 ( card ) ，左边的表如果符合条件就显示，不符合则补 NULL 。
完整显示两张表的全部数据。
在 MySQL 中，事务其实是一个最小的不可分割的工作单元。事务能够 保证一个业务的完整性 。
比如我们的银行转账：
在实际项目中，假设只有一条 SQL 语句执行成功，而另外一条执行失败了，就会出现数据前后不一致。
因此，在执行多条有关联 SQL 语句时， 事务 可能会要求这些 SQL 语句要么同时执行成功，要么就都执行失败。
在 MySQL 中，事务的 自动提交 状态默认是开启的。
自动提交的作用 ：当我们执行一条 SQL 语句的时候，其产生的效果就会立即体现出来，且不能 回滚 。
什么是回滚？举个例子：
可以看到，在执行插入语句后数据立刻生效，原因是 MySQL 中的事务自动将它 提交 到了数据库中。那么所谓 回滚 的意思就是，撤销执行过的所有 SQL 语句，使其回滚到 最后一次提交 数据时的状态。
在 MySQL 中使用 ROLLBACK 执行回滚：
由于所有执行过的 SQL 语句都已经被提交过了，所以数据并没有发生回滚。那如何让数据可以发生回滚？
将自动提交关闭后，测试数据回滚：
那如何将虚拟的数据真正提交到数据库中？使用 COMMIT :
事务的实际应用 ，让我们再回到银行转账项目：
这时假设在转账时发生了意外，就可以使用 ROLLBACK 回滚到最后一次提交的状态：
这时我们又回到了发生意外之前的状态，也就是说，事务给我们提供了一个可以反悔的机会。假设数据没有发生意外，这时可以手动将数据真正提交到数据表中：COMMIT 。
事务的默认提交被开启 ( @@AUTOCOMMIT = 1 ) 后，此时就不能使用事务回滚了。但是我们还可以手动开启一个事务处理事件，使其可以发生回滚：
仍然使用 COMMIT 提交数据，提交后无法再发生本次事务的回滚。
事务的四大特征：
事务的隔离性可分为四种 ( 性能从低到高 ) ：
查看当前数据库的默认隔离级别：
修改隔离级别：
测试 READ UNCOMMITTED ( 读取未提交 ) 的隔离性：
由于小明的转账是在新开启的事务上进行操作的，而该操作的结果是可以被其他事务（另一方的淘宝店）看见的，因此淘宝店的查询结果是正确的，淘宝店确认到账。但就在这时，如果小明在它所处的事务上又执行了 ROLLBACK 命令，会发生什么？
这就是所谓的 脏读 ，一个事务读取到另外一个事务还未提交的数据。这在实际开发中是不允许出现的。
把隔离级别设置为 READ COMMITTED ：
这样，再有新的事务连接进来时，它们就只能查询到已经提交过的事务数据了。但是对于当前事务来说，它们看到的还是未提交的数据，例如：
但是这样还有问题，那就是假设一个事务在操作数据时，其他事务干扰了这个事务的数据。例如：
虽然 READ COMMITTED 让我们只能读取到其他事务已经提交的数据，但还是会出现问题，就是 在读取同一个表的数据时，可能会发生前后不一致的情况。* 这被称为* 不可重复读现象 ( READ COMMITTED ) 。
将隔离级别设置为 REPEATABLE READ ( 可被重复读取 ) :
测试 REPEATABLE READ ，假设在两个不同的连接上分别执行 START TRANSACTION :
当前事务开启后，没提交之前，查询不到，提交后可以被查询到。但是，在提交之前其他事务被开启了，那么在这条事务线上，就不会查询到当前有操作事务的连接。相当于开辟出一条单独的线程。
无论小张是否执行过 COMMIT ，在小王这边，都不会查询到小张的事务记录，而是只会查询到自己所处事务的记录：
这是 因为小王在此之前开启了一个新的事务 ( START TRANSACTION ) * ，那么* 在他的这条新事务的线上，跟其他事务是没有联系的 ，也就是说，此时如果其他事务正在操作数据，它是不知道的。
然而事实是，在真实的数据表中，小张已经插入了一条数据。但是小王此时并不知道，也插入了同一条数据，会发生什么呢？
报错了，操作被告知已存在主键为 6 的字段。这种现象也被称为 幻读，一个事务提交的数据，不能被其他事务读取到 。
顾名思义，就是所有事务的 写入操作 全都是串行化的。什么意思？把隔离级别修改成 SERIALIZABLE :
还是拿小张和小王来举例：
此时会发生什么呢？由于现在的隔离级别是 SERIALIZABLE ( 串行化 ) ，串行化的意思就是：假设把所有的事务都放在一个串行的队列中，那么所有的事务都会按照 固定顺序执行 ，执行完一个事务后再继续执行下一个事务的 写入操作 ( 这意味着队列中同时只能执行一个事务的写入操作 ) 。
根据这个解释，小王在插入数据时，会出现等待状态，直到小张执行 COMMIT 结束它所处的事务，或者出现等待超时。
转载： https://github.com/baa-god/sql_node/blob/master/mysql/
㈤ MySQL基本调度策略浅析
MySQL允许影响语句的调度特性，这样会使来自几个客户机的查询更好地协作，从而单个客户机不会被锁定太长的时间。更改调度特性还能保证特定的查询处理得更快。我们先来看一下MySQL的缺省调度策略，然后来看看为改变这个策略可使用什么样的选项。出于讨论的目的，假设执行检索( SELECT)的客户机程序为读取程序。执行修改表操作( DELETE，INSERT，REPLACE 或UP DATE)的另一个客户机程序为写入程序。
MySQL的基本调度策略可总结如下：
◆写入请求应按其到达的次序进行处理。
◆写入具有比读取更高的优先权。
在表锁的帮助下实现调度策略。客户机程序无论何时要访问表，都必须首先获得该表的锁。可以直接用LOCK TABLES 来完成这项工作，但一般服务器的锁管理器会在需要时自动获得锁。在客户机结束对表的处理时，可释放表上的锁。直接获得的锁可用UNLOCK TABLES 释放，但服务器也会自动释放它所获得的锁。
执行写操作的客户机必须对表具有独占访问的锁。在写操作进行中，由于正在对表进行数据记录的删除、增加或更改，所以该表处于不一致状态，而且该表上的索引也可能需要作相应的更新。如果表处于不断变化中，此时允许其他客户机访问该表会出问题。让两个客户机同时写同一个表显然不好，因为这样会很快使该表不可用。允许客户机读不断变仿大化的表也不是件好事，因为可能在读该表的那一刻正好正在对它进行更改，其结果是不正确的。执行读取操作的客户机必须有一把防止其他客户机写该表的锁，以保证读表的过程中表不出现变化。不过，该锁无需对读取操作提供独占访问。此锁还允许其他客户机同时对表进行读取。读取备数竖不会更改表，所有没必要阻止其它客户机对该表进行读取。
MySQL允许借助几个查询限修饰符对其调度策略施加影响。其中之一是DELETE、INSERT、LOAD DATA、REPLACE 和UP DATE 语句的LOW_PRIORITY 关键字。另一个是SELECT 语句的HIGH_PRIORITY 关键字。第三个是INSERT 和REPLACE 语句的DELAYED 关键字。
LOW_PRIORITY 关键字按如下影响调度。一般情况下，如果某个表的写入操作在表正被读取时到达，写入程序被阻塞，直到读取程序完成，因为一旦某个查询开始，就不能中断。如果另一读取请求在写入程序等待时到达，此读取程序也被阻塞，因为缺省的调度策略为写入程序具有比读取程序高的优先级。在第一个读取程序结束时，写入程序继续，在此写入程序结束时，第二个读取程序开始。
如果写入请求为LOW_PRIORITY 的请求，则不将该写入操作视为具有比读取操作优先级高的操作。在此情形下，如果第二个读取请求在写入程毕春序等待时到达，则让第二个读取操作排在等待的写入操作之前。仅当没有其他读取请求时，才允许写入程序执行。这种调度的更改从理论上说，其含义为LOW_PRIORITY 写入可能会永远被阻塞。当正在处理前面的读取请求时，只要另一个读取请求到达，这个新的请求允许排在LOW_PRIORITY 写入之前。
SELECT 查询的HIGH_PRIORITY 关键字作用类似。它使SELECT 插在正在等待的写入操作之前，即使该写入操作具有正常的优先级。INSERT 的ELAYED 修饰符作用如下，在表的一个INSERT DELAYED 请求到达时，服务器将相应的行放入一个队列，并立即返回一个状态到客户机程序，以便该客户机程序可以继续执行，即使这些行尚未插入表中。如果读取程序正在对表进行读取，那么队列中的行挂起。在没有读取时，服务器开始开始插入延迟行队列中的行。服务器不时地停下来看看是否有新的读取请求到达，并进行等待。如果是这样，延迟行队列将挂起，并允许读取程序继续。在没有其他的读取操作时，服务器再次开始插入延迟行。这个过程一直进行到延迟行队列空为止。
此并非出现在所有MySQL版本中。下面的表列出了这些修饰符和支持这些修饰符的MySQL版本。可利用此表来判断所使用的MySQL版本具有什么样的功能：
如果其他客户机可能执行冗长的SELECT 语句，而且您不希望等待插入完成，此时INSERT DELAYED 很有用。发布INSERT DELAYED 的客户机可以更快地继续执行，因为服务器只是简单地将要插入的行插入。不过应该对正常的INSERT 和INSERT DELAYED 性能之间的差异有所认识。如果INSERT DELAYED 存在语法错误，则向客户机发出一个错误，如果正常，便不发出信息。例如，在此语句返回时，不能相信所取得的AUTO_INCREMENT 值。也得不到惟一索引上的重复数目的计数。之所以这样是因为此插入操作在实际的插入完成前返回了一个状态。其他还表示，如果INSERT DELAYED 语句的行在等待插入中被排队，并且服务器崩溃或被终止(用kill -9)，那么这些行将丢失。正常的TERM 终止不会这样，服务器会在退出前将这些行插入。
㈥ sql数据库出现队列问题如何解决
sql数据库出现队列问题可以这样解决：文中从 select ... limit 1 这一点开始，也就是 limit 1这东西出现开始，思路就错了。错就错在worker不应该管理任务的分发（当worker会去卜颤老回写mysql，就参与了任务的型升分发），只负责单调领任务即可。分发的事情交给独立的进洞备程配合mq或者redis进行。
㈦ 如何使用MySQL实现队列
这完全是文不对题啊，队列是一种先进先出的空宴数据结构，通常改亏哪在各种编程语言中都提供相应的类库支持，但MySQL是一个关系型数据库管理系统，并不直接提供这种功能，也不应该提供核码这种功能。
如果真需要先进先出，就把查询的结果放入到对应高级语言的队列中即可。
㈧ mysql 什么时候分区 什么时候分表
一，什么是mysql分表，分区
什么是分表，从表面意思上看呢，就是把一张表分成N多个小表，具体请看mysql分表的3种方法
什么是分区，分区呢就是把一张表的数据分成N多个区块，这些区块可以在同一个磁盘上，也可以在不同的磁盘上
一，先说一下为什么要分表
当一张的数据达到几百万时，你查询一次所花的时间会变多，如果有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减小数据库的负担，缩短查询时间。
根据个人经验，mysql执行一个sql的过程如下：
1,接收到sql;2,把sql放到排队队列中 ;3,执行sql;4,返回执行结果。在这个执行过程中最花时间在什么地方呢？第一，是排队等待的时间，第二，sql的执行时间。其实这二个是一回事，等待的同时，肯定有sql在执行。所以我们要缩短sql的执行时间。
mysql中有一种机制是表锁定和行锁定，为什么要出现这种机制，是为了保证数据的完整性，我举个例子来说吧，如果有二个sql都要修改同一张表的同一条数据，这个时候怎么办呢，是不是二个sql都可以同时修改这条数据呢？很显然mysql对这种情况的处理是，一种是表锁定（myisam存储引擎），一个是行锁定（innodb存储引擎）。表锁定表示你们都不能对这张表进行操作，必须等我对表操作完才行。行锁定也一样，别的sql必须等我对这条数据操作完了，才能对这条数据进行操作。如果数据太多，一次执行的时间太长，等待的时间就越长，这也是我们为什么要分表的原因。
二，分表
1，做mysql集群，例如：利用mysql cluster ，mysql proxy，mysql replication，drdb等等
有人会问mysql集群，根分表有什么关系吗？虽然它不是实际意义上的分表，但是它启到了分表的作用，做集群的意义是什么呢？为一个数据库减轻负担，说白了就是减少sql排队队列中的sql的数量，举个例子：有10个sql请求，如果放在一个数据库服务器的排队队列中，他要等很长时间，如果把这10个sql请求，分配到5个数据库服务器的排队队列中，一个数据库服务器的队列中只有2个，这样等待时间是不是大大的缩短了呢？这已经很明显了。所以我把它列到了分表的范围以内，我做过一些mysql的集群：
linux mysql proxy 的安装，配置，以及读写分离
mysql replication 互为主从的安装及配置，以及数据同步
优点：扩展性好，没有多个分表后的复杂操作（php代码）
缺点：单个表的数据量还是没有变，一次操作所花的时间还是那么多，硬件开销大。
2，预先估计会出现大数据量并且访问频繁的表，将其分为若干个表
这种预估大差不差的，论坛里面发表帖子的表，时间长了这张表肯定很大，几十万，几百万都有可能。 聊天室里面信息表，几十个人在一起一聊一个晚上，时间长了，这张表的数据肯定很大。像这样的情况很多。所以这种能预估出来的大数据量表，我们就事先分出个N个表，这个N是多少，根据实际情况而定。以聊天信息表为例：
我事先建100个这样的表，message_00,message_01,message_02..........message_98,message_99.然后根据用户的ID来判断这个用户的聊天信息放到哪张表里面，你可以用hash的方式来获得，可以用求余的方式来获得，方法很多，各人想各人的吧。下面用hash的方法来获得表名：
查看复制打印?
<?php
function get_hash_table($table,$userid) {
$str = crc32($userid);
if($str<0){
$hash = "0".substr(abs($str), 0, 1);
}else{
$hash = substr($str, 0, 2);
}
return $table."_".$hash;
}
echo get_hash_table('message','user18991'); //结果为message_10
echo get_hash_table('message','user34523'); //结果为message_13
?>
说明一下，上面的这个方法，告诉我们user18991这个用户的消息都记录在message_10这张表里，user34523这个用户的消息都记录在message_13这张表里，读取的时候，只要从各自的表中读取就行了。
优点：避免一张表出现几百万条数据，缩短了一条sql的执行时间
缺点：当一种规则确定时，打破这条规则会很麻烦，上面的例子中我用的hash算法是crc32，如果我现在不想用这个算法了，改用md5后，会使同一个用户的消息被存储到不同的表中，这样数据乱套了。扩展性很差。
3，利用merge存储引擎来实现分表
我觉得这种方法比较适合，那些没有事先考虑，而已经出现了得，数据查询慢的情况。这个时候如果要把已有的大数据量表分开比较痛苦，最痛苦的事就是改代码，因为程序里面的sql语句已经写好了，现在一张表要分成几十张表，甚至上百张表，这样sql语句是不是要重写呢？举个例子，我很喜欢举子
mysql>show engines;的时候你会发现mrg_myisam其实就是merge。
查看复制打印?
mysql> CREATE TABLE IF NOT EXISTS `user1` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `name` varchar(50) DEFAULT NULL,
-> `sex` int(1) NOT NULL DEFAULT '0',
-> PRIMARY KEY (`id`)
-> ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
Query OK, 0 rows affected (0.05 sec)
mysql> CREATE TABLE IF NOT EXISTS `user2` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `name` varchar(50) DEFAULT NULL,
-> `sex` int(1) NOT NULL DEFAULT '0',
-> PRIMARY KEY (`id`)
-> ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
Query OK, 0 rows affected (0.01 sec)
mysql> INSERT INTO `user1` (`name`, `sex`) VALUES('张映', 0);
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO `user2` (`name`, `sex`) VALUES('tank', 1);
Query OK, 1 row affected (0.00 sec)
mysql> CREATE TABLE IF NOT EXISTS `alluser` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `name` varchar(50) DEFAULT NULL,
-> `sex` int(1) NOT NULL DEFAULT '0',
-> INDEX(id)
-> ) TYPE=MERGE UNION=(user1,user2) INSERT_METHOD=LAST AUTO_INCREMENT=1 ;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> select id,name,sex from alluser;
+----+--------+-----+
| id | name | sex |
+----+--------+-----+
| 1 | 张映 | 0 |
| 1 | tank | 1 |
+----+--------+-----+
2 rows in set (0.00 sec)
mysql> INSERT INTO `alluser` (`name`, `sex`) VALUES('tank2', 0);
Query OK, 1 row affected (0.00 sec)
mysql> select id,name,sex from user2
-> ;
+----+-------+-----+
| id | name | sex |
+----+-------+-----+
| 1 | tank | 1 |
| 2 | tank2 | 0 |
+----+-------+-----+
2 rows in set (0.00 sec)
从上面的操作中，我不知道你有没有发现点什么？假如我有一张用户表user，有50W条数据，现在要拆成二张表user1和user2，每张表25W条数据，
INSERT INTO user1(user1.id,user1.name,user1.sex)SELECT (user.id,user.name,user.sex)FROM user where user.id <= 250000
INSERT INTO user2(user2.id,user2.name,user2.sex)SELECT (user.id,user.name,user.sex)FROM user where user.id > 250000
这样我就成功的将一张user表，分成了二个表，这个时候有一个问题，代码中的sql语句怎么办，以前是一张表，现在变成二张表了，代码改动很大，这样给程序员带来了很大的工作量，有没有好的办法解决这一点呢？办法是把以前的user表备份一下，然后删除掉，上面的操作中我建立了一个alluser表，只把这个alluser表的表名改成user就行了。但是，不是所有的mysql操作都能用的
a，如果你使用 alter table 来把 merge 表变为其它表类型，到底层表的映射就被丢失了。取而代之的，来自底层 myisam 表的行被复制到已更换的表中，该表随后被指定新类型。
b，网上看到一些说replace不起作用，我试了一下可以起作用的。晕一个先
mysql> UPDATE alluser SET sex=REPLACE(sex, 0, 1) where id=2;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from alluser;
+----+--------+-----+
| id | name | sex |
+----+--------+-----+
| 1 | 张映 | 0 |
| 1 | tank | 1 |
| 2 | tank2 | 1 |
+----+--------+-----+
3 rows in set (0.00 sec)
c，一个 merge 表不能在整个表上维持 unique 约束。当你执行一个 insert，数据进入第一个或者最后一个 myisam 表（取决于 insert_method 选项的值）。mysql 确保唯一键值在那个 myisam 表里保持唯一，但不是跨集合里所有的表。
d,当你创建一个 merge 表之时，没有检查去确保底层表的存在以及有相同的机构。当 merge 表被使用之时，mysql 检查每个被映射的表的记录长度是否相等，但这并不十分可靠。如果你从不相似的 myisam 表创建一个 merge 表，你非常有可能撞见奇怪的问题。
优点：扩展性好，并且程序代码改动的不是很大
缺点：这种方法的效果比第二种要差一点
三，总结一下
上面提到的三种方法，我实际做过二种，第一种和第二种。第三种没有做过，所以说的细一点。哈哈。做什么事都有一个度，超过个度就过变得很差，不能一味的做数据库服务器集群，硬件是要花钱买的，也不要一味的分表，分出来1000表，mysql的存储归根到底还以文件的形势存在硬盘上面，一张表对应三个文件，1000个分表就是对应3000个文件，这样检索起来也会变的很慢。我的建议是
方法1和方法2结合的方式来进行分表
方法1和方法3结合的方式来进行分表
我的二个建议适合不同的情况，根据个人情况而定，我觉得会有很多人选择方法1和方法3结合的方式
二，mysql分表和分区有什么区别呢
1，实现方式上
a），mysql的分表是真正的分表，一张表分成很多表后，每一个小表都是完正的一张表，都对应三个文件，一个.MYD数据文件，.MYI索引文件，.frm表结构文件。
[root@BlackGhost test]# ls |grep user
alluser.MRG
alluser.frm
user1.MYD
user1.MYI
user1.frm
user2.MYD
user2.MYI
user2.frm
Php代码
[root@BlackGhost test]# ls |grep user
alluser.MRG
alluser.frm
user1.MYD
user1.MYI
user1.frm
user2.MYD
user2.MYI
user2.frm
简单说明一下，上面的分表呢是利用了merge存储引擎（分表的一种），alluser是总表，下面有二个分表，user1，user2。他们二个都是独立的表，取数据的时候，我们可以通过总表来取。这里总表是没有.MYD,.MYI这二个文件的，也就是说，总表他不是一张表，没有数据，数据都放在分表里面。我们来看看.MRG到底是什么东西
[root@BlackGhost test]# cat alluser.MRG |more
user1
user2
#INSERT_METHOD=LAST
Php代码
[root@BlackGhost test]# cat alluser.MRG |more
user1
user2
#INSERT_METHOD=LAST
从上面我们可以看出，alluser.MRG里面就存了一些分表的关系，以及插入数据的方式。可以把总表理解成一个外壳，或者是联接池。
b），分区不一样，一张大表进行分区后，他还是一张表，不会变成二张表，但是他存放数据的区块变多了。
[root@BlackGhost test]# ls |grep aa
aa#P#p1.MYD
aa#P#p1.MYI
aa#P#p3.MYD
aa#P#p3.MYI
aa.frm
aa.par
Php代码
[root@BlackGhost test]# ls |grep aa
aa#P#p1.MYD
aa#P#p1.MYI
aa#P#p3.MYD
aa#P#p3.MYI
aa.frm
aa.par
从上面我们可以看出，aa这张表，分为二个区，p1和p3，本来是三个区，被我删了一个区。我们都知道一张表对应三个文件.MYD,.MYI,.frm。分区呢根据一定的规则把数据文件和索引文件进行了分割，还多出了一个.par文件，打开.par文件后你可以看出他记录了，这张表的分区信息，根分表中的.MRG有点像。分区后，还是一张，而不是多张表。
2，数据处理上
a），分表后，数据都是存放在分表里，总表只是一个外壳，存取数据发生在一个一个的分表里面。看下面的例子：
select * from alluser where id=’12′表面上看，是对表alluser进行操作的，其实不是的。是对alluser里面的分表进行了操作。
b），分区呢，不存在分表的概念，分区只不过把存放数据的文件分成了许多小块，分区后的表呢，还是一张表。数据处理还是由自己来完成。
3，提高性能上
a），分表后，单表的并发能力提高了，磁盘I/O性能也提高了。并发能力为什么提高了呢，因为查寻一次所花的时间变短了，如果出现高并发的话，总表可以根据不同的查询，将并发压力分到不同的小表里面。磁盘I/O性能怎么搞高了呢，本来一个非常大的.MYD文件现在也分摊到各个小表的.MYD中去了。
b），mysql提出了分区的概念，我觉得就想突破磁盘I/O瓶颈，想提高磁盘的读写能力，来增加mysql性能。
在这一点上，分区和分表的测重点不同，分表重点是存取数据时，如何提高mysql并发能力上；而分区呢，如何突破磁盘的读写能力，从而达到提高mysql性能的目的。
4），实现的难易度上
a），分表的方法有很多，用merge来分表，是最简单的一种方式。这种方式根分区难易度差不多，并且对程序代码来说可以做到透明的。如果是用其他分表方式就比分区麻烦了。
b），分区实现是比较简单的，建立分区表，根建平常的表没什么区别，并且对开代码端来说是透明的。
三，mysql分表和分区有什么联系呢
1，都能提高mysql的性高，在高并发状态下都有一个良好的表面。
2，分表和分区不矛盾，可以相互配合的，对于那些大访问量，并且表数据比较多的表，我们可以采取分表和分区结合的方式（如果merge这种分表方式，不能和分区配合的话，可以用其他的分表试），访问量不大，但是表数据很多的表，我们可以采取分区的方式等。
㈨ mysql 查询后更新 高并发
一种：使用行锁，SELECT `id` FROM `urls` ORDER BY `c_time` LIMIT 1 FOR UPDATE
坏处：进程阻塞
另外一种，使用更新乱租队列（添加一张记录更新的时间队列表，执行更新前，去队列里查询最新的更新时间，所有针对这个id的访问都先把时间插入到时间队列表），枯镇队列可没陪粗使用库，也可以使用缓存（redis等）