黑鹰

36计帮你教出好孩子

825211@qq.com( 黑鹰) — Mon, 23 Nov 2009 01:21:28 GMT

孩子优秀只是因为教育方法更优秀。
　　没有教不好的孩子，只有不好的教育方法。家长、老师常常因为孩子进步缓慢而着急，由此或者粗暴地给孩子戴上“脑子笨”、“性格难以改变”之类的帽子，或者自认为学识浅、水平低，不会教育孩子。实际上，只要方法妥当，任何孩子都是优秀的；只要用心，总能找到合适的教育方法。
　　一、扮弱计——让孩子充当一次“小大人”
　　父母常常抱怨现在的孩子对父母漠不关心，缺少责任感，他们不知道，孩子的责任感是要从小培养的，如果你总在孩子面前表现出一副风雨无惧的样子，孩子就会认为父母是不需要他们关心照顾的。因此，父母们不妨偶尔扮一次弱，向孩子求助，你会惊奇地发现孩子竟因此变成了懂事的“小大人”，而你也可以从孩子的帮助中获得很多东西。
　　二、补强计——让孩子由自卑变自信。
　　美国加州大家哲学博士詹姆斯.多伯林提出了“补强法则”。当一个人的行为得到满意的结果时，这种行为就会重复出现。因此，当孩子受到认可时，他（她）的自信就会被激发出来，不断重复令人满意的行为，直至摆脱自卑，成为自信上进的好孩子。
　　三、诱导计——帮孩子跨过厌学的泥潭。
　　几乎每个孩子都多多少少有些厌学情绪，这是可以理解但却不能放任自流的，因为这种情绪会阻碍孩子学习的热情，给孩子的成长带来难以估量的影响。然而强制孩子学习也不是好办法，这只会加深孩子的反感，聪明的做法是诱导孩子学习的兴趣，让孩子自动自发地学习。
　　　四、冷淡计——让孩子有一点自控能力。
　　今天的孩子大多是独生子女，受到家人无微不至的关怀和照顾，然而这样的生活却让孩子养成了任性的习惯，这个坏习惯将给孩子未来的生活埋下巨大隐患。专家建议孩子任性时不妨试试冷处理，这会使孩子因得不到注意而自动收敛脾气。
　　五、授挫计——给孩子一个体验失败的机会。
　　美国教育家卡乐尔.桑德堡说：“顺境当然可以出人才，但逆境也可以出人才。而且在逆境中经过挫折和千锤百炼成长起来的孩子才更具生存竞争力。”也就是说为了增强孩子的耐挫力，父母们不妨有意识地给孩子创造一些适度的挫折情意，这种挫折教育对增强孩子的心理承受能力大有好处。
　　六、放手计——培养孩子自己的事情自己做。
　　不要什么都为孩子做好，家长应当试着放开手，让孩子自主地去做，第一次也许做不好，但以后就会做得又快又好。千万不要做包办父母，放开手为孩子创造做事的机会和平台，孩子才能有自立能力，父母们也会少些麻烦。
　　七、纵容计——让孩子在“淘气”中开发潜能
　　一些父母抱怨自己的孩子“太淘气”是“破坏狂”，其实这类孩子往往很聪明，求知欲、好奇心都比较强，意志力也比一般孩子来得坚定。因此，聪明的家长要试着“纵容”孩子的淘气和“破坏”行为，并借机挖掘潜能，培养兴趣，说不定你的孩子就是另一个“爱迪生”。
　　八、处罚计——让孩子正视自己的错误。
　　教育孩子就要赏罚分明，孩子做的好要给予奖励，但孩子做错事时一定不要姑息，哪怕只是小错也要进行适度的处罚，这样孩子才能正视自己的错误，及时改正，免得在错误里越陷越深。
　　九、制冷计——给自负的孩子“泼冷水”。
　　自负是指自我评价过高，目中无人，这种心理对孩子的成长是极为不利的，因此一旦发现孩子自负的苗头，父母就应当运用“制冷”的手段，适时地给孩子泼点冷水，让孩子学会理性地评价自己，正确地认识自己。
　　十、包容计——让孩子感受父母无条件的爱。
　　孩子也许不够聪明，也许有很多缺点，可是作为父母，你绝对不能对孩子存有偏见，羞辱或嫌弃自己的孩子。对孩子一定要包容，要有信心，你就会得到一个怎样的孩子。
　　十一、样板计——父母要给孩子当好第一任老师。
　　父母是孩子的榜样，孩子是父母的镜子，父母的言行举止都会影响到孩子。因此父母要严于律已，处处事事以自己的正确言行为孩子树立榜样，引导孩子健康成长。
　　十二、鼓励计——给孩子不断进取的力量。
　　孩子很容易对自己失去信心，很容易因为了困难而放弃努力，因此，家长要不断地鼓励孩子，给他们前进的勇气和必胜的信心，这样孩子就能带着父母的期待改正缺点，不断进步。
　　十三、倾听计——认真了解孩子的感受。
　　每个孩子都有自己的心声，家长一定要耐心地去倾听，才能真正了解孩子的想法、感受，才能对孩子生理及心理上的问题、变化做出及时而细致的处理。有了这样的基础，亲子之间才能良好沟通，建立良好、和谐的亲子关系。
　　十四、赏善计——让孩子在赞美声中进步。
　　教育学家认为，教育孩子，奖励是比惩罚更有效的方式。因此他们建议，用奖励正确来代替惩罚错误，用肯定优点来代替否定缺点，这样既可以避免给孩子造成伤害，又可以使孩子取得更好的进步。
　　十五、点拨计——巧妙地提示孩子自觉走向正途。
　　絮絮叨叨的说教，凡事替孩子包办的父母是孩子最不喜欢的，聪明的家长只会在孩子遇到难题或行为错误时，从旁稍加提示引导，帮孩子解决疑难。这样，孩子明白了道理，家长也达到了教育的目的。
　　十六、虚拟计——让孩子产生“我很棒”的自我感觉。
　　日本教育家铃木镇一说：“有了天才的感觉，你会成为天才；有了英雄的感觉，你会成为英雄。孩子找到了好孩子的感觉，他就会成为好孩子。”用虚拟的手段，给孩子制造一个“我很棒”的自我感觉，他就会逐渐“棒”起来。
　　十七、容过计——让孩子在错误中学到更多。
　　生活中，孩子总难免有些过失、错误。有的是无意，有的是有意的。如果孩子所犯过错的性质不是很严重，那么家长就不妨给予宽容、谅解，这样孩子不仅会在内疚自责中更认真地改正错误，还可以使孩子形成良好的宽容心态。
　　十八、训诫计——让孩子认识错误、改过自新。
　　孩子就是孩子，会不断地出现各种各样的问题和错误，有些错误可以宽容，而有些错误是不能姑息的。必须对孩子进行合理、有效的批评，以保证孩子不再犯类似的错误，即使是再宽大的父母，也不能让这种合理的管教缺位。
　　十九、熏陶计——在生活中给孩子好的影响。
　　家庭是孩子的第一课堂，家庭教育给孩子的影响是深远而巨大的。因此，父母如果能在家庭生活中，通过讲故事等方式，培养孩子健康的兴趣爱好，陶冶孩子的情趣、品行，那么就可以让孩子更健康地成长。
　　二十、疏导计——让孩子由对立变成合作。
　　大禹治水的成功之处在于“疏”而不在“堵”，父母也可以从这种方法中得到启示。在教育孩子时太过专制只会引起孩子的逆反，让孩子跟你“对着干”，但如果采取明智、开放的疏导策略，孩子就会愿意跟你愉快合作。
　　二十一、尊子计——让孩子与父母贴得更近。
　　亲子间之所以出现冲突矛盾，往往是因为父母对孩子不够尊重，使孩子心怀恐惧、不满，拉开了彼此的距离。其实孩子也需要尊重，那么他们一定会成为最受孩子欢迎的父母。
　　二十二、对等计——与孩子实现良好的沟通。
　　与孩子良好沟通的前提，就是平等地对待孩子，做孩子的好朋友。这样孩子才会愿意向你说出心里话，家长才可以及时帮孩子摆脱各种问题。如果家长总是摆着家长架子，专制地要求孩子服从自己，那么亲子间沟通的大门就会慢慢关上。
　　二十三、攻防计——先给孩子打好“预防针”。
　　兵法上说，最好的防守就是进攻。在教育孩子时也是这样，与其孩子出现问题后，再去管教、愤怒，还不如提前就给孩子打好“预防针”，提高孩子的“免疫力”，让孩子少走弯路，少犯错误。
　　二十四、训俭计——帮孩子克服骄奢之气。
　　现在孩子都是家里的“小皇帝”、“小公主”，要风得风，要雨得雨。一些孩子就养成了骄奢的习惯，花钱大手大脚，不知爱惜物品，这种习惯对孩子的健康成长是极为不利的，因此家长应理直气壮地教育孩子勤俭节约，帮孩子养成节俭的习惯，这才是真正的爱孩子。
　　二十五、伴教计——在参与中教出好孩子。
　　如果父母能够参与孩子的生活，多抽时间陪伴孩子做一些事，那么不但可以增进亲子感情，还可以鼓舞孩子，同时父母还可以对孩子多一些了解，这于开发孩子的潜力、培养孩子成才是非常重要的。
　　二十六、防微计——别让孩子的小毛病变成大问题。
　　生活中，孩子有时会有一些小毛病，比如霸道、无礼、懒惰等等，这时候家长就要注意了，问题虽小，但也要严管，防微杜渐，否则这些小毛病会变成大问题，那时候家长再想让孩子改正，就不那么容易了。不要姑息孩子的小毛病，严管同样是爱的表现。
　　二十七、劝和计——让孩子与老师相互包容。
　　老师与学生之间也会发生一些摩擦和误会，这时家长就要担任“和事佬”的角色，帮助双方消除矛盾、误会，互相理解、互相包容。让孩子照样尊敬老师，老师继续爱护孩子。
　　二十八、立规计——用合理的规则让孩子学会自控。
　　孩子的自控能力较差、而家长“不要这样”、“不要那样”的说教又容易引起孩子的厌烦，因此家长可以为孩子建立一套行之有效的行为规则，作为孩子判断自己行为的依据，以此来约束自己的行为。
　　二十九、减负计——别给孩子太大的压力。
　　生活中，有心理障碍的孩子越来越多，而儿童心理学家指出，压力过大是导致孩子出现心理问题的一个重要原因，给孩子减负已经成了当务之急。为了让孩子健康成长，家长们请别给孩子太大的压力。
　　三十、激发计——用刺激孩子的方式让孩子爱学习。
　　教育孩子要找对方式，当劝导、说教都不奏效时，家长们不妨试试这招儿激发计。利用孩子的好胜心、逆反心甚至嫉妒心理来故意刺激孩子，让他们由不爱学习变成积极学习。
　　三十一、悦纳计——让孩子喜欢并接受自己。
　　如果孩子不能全面地认识自己、看到自己的长处，那就会出现很多问题。比如自卑、嫉妒别人等等。因此，家长们要让孩子们看到自己的优点，要让孩子喜欢自己，这样孩子才能自信地面对生活。
　　　三十二、用忍计——温和地纠正孩子的“出格”行为。
　　孩子常常会做出一些令父母无法容忍的“出格”行为，而“急风骤雨”式的教育只会使孩子走向极端，因此，家长们只能“戒急用忍”，压下火气，多理解孩子多包容孩子，在此基础上引导孩子，这样才能把孩子引向正途。
　　三十三、励勇计——培养孩子大胆探索的勇敢个性。
　　生活中，常常是那些勇于探索、大胆无畏的人才能取得杰出的成就，获得幸福。因此，父母们为了孩子的未来着想，不要总是对孩子过度保护，不要过分强调培养“听话”的孩子，而是应该多给孩子一些锻炼的机会，鼓励他们做勇敢的孩子。
　　三十四、感化计——以真情感动孩子的心灵。
　　教育孩子，不能光是说教、责骂、劝导，有时候还必须要以情感之，这样才能撼动孩子的心灵，达到教育的最佳效果。但是，要感化孩子必须要情真意切，否则效果就会大打折扣。
　　三十五、平等计——培养一个胸怀开阔的孩子。
　　现在的孩子大多是独生子女，个个都是“小太阳”，他们习惯以自我为中心，然而这样的性格对人际交往是极为不利的。因此，生活中，父母们应注意不要给孩子特殊的地位，培养他们分享、合作的精神，逐步培养出一个胸怀开阔的孩子。
　　　三十六、苦磨计——培养孩子的意志和毅力。
　　现在的孩子面临的是一个处处充满竞争的社会，而很多孩子由于生活过于安逸，往往缺少战胜困难的勇气。因此，聪明的父母应该多让孩子经受一些艰难困苦的磨练，以培养他们坚韧不拔的意志和毅力，这样他们才能在未来的竞争中取胜。

理解MySQL——索引与优化转

825211@qq.com( 黑鹰) — Sat, 14 Nov 2009 12:17:05 GMT

理解MySQL——索引与优化
写在前面：索引对查询的速度有着至关重要的影响，理解索引也是进行数据库性能调优的起点。考虑如下情况，假设数据库中一个表有10^6条记录，DBMS的页面大小为4K，并存储100条记录。如果没有索引，查询将对整个表进行扫描，最坏的情况下，如果所有数据页都不在内存，需要读取10^4个页面，如果这10^4个页面在磁盘上随机分布，需要进行10^4次I/O，假设磁盘每次I/O时间为10ms(忽略数据传输时间)，则总共需要100s(但实际上要好很多很多)。如果对之建立B-Tree索引，则只需要进行log100(10^6)=3次页面读取，最坏情况下耗时30ms。这就是索引带来的效果，很多时候，当你的应用程序进行SQL查询速度很慢时，应该想想是否可以建索引。进入正题：
第二章、索引与优化
1、选择索引的数据类型
MySQL支持很多数据类型，选择合适的数据类型存储数据对性能有很大的影响。通常来说，可以遵循以下一些指导原则：
(1)越小的数据类型通常更好：越小的数据类型通常在磁盘、内存和CPU缓存中都需要更少的空间，处理起来更快。
(2)简单的数据类型更好：整型数据比起字符，处理开销更小，因为字符串的比较更复杂。在MySQL中，应该用内置的日期和时间数据类型，而不是用字符串来存储时间；以及用整型数据类型存储IP地址。
(3)尽量避免NULL：应该指定列为NOT NULL，除非你想存储NULL。在MySQL中，含有空值的列很难进行查询优化，因为它们使得索引、索引的统计信息以及比较运算更加复杂。你应该用0、一个特殊的值或者一个空串代替空值。

1.1、选择标识符
选择合适的标识符是非常重要的。选择时不仅应该考虑存储类型，而且应该考虑MySQL是怎样进行运算和比较的。一旦选定数据类型，应该保证所有相关的表都使用相同的数据类型。
(1) 整型：通常是作为标识符的最好选择，因为可以更快的处理，而且可以设置为AUTO_INCREMENT。
(2) 字符串：尽量避免使用字符串作为标识符，它们消耗更好的空间，处理起来也较慢。而且，通常来说，字符串都是随机的，所以它们在索引中的位置也是随机的，这会导致页面分裂、随机访问磁盘，聚簇索引分裂（对于使用聚簇索引的存储引擎）。
2、索引入门
对于任何DBMS，索引都是进行优化的最主要的因素。对于少量的数据，没有合适的索引影响不是很大，但是，当随着数据量的增加，性能会急剧下降。
如果对多列进行索引(组合索引)，列的顺序非常重要，MySQL仅能对索引最左边的前缀进行有效的查找。例如：
假设存在组合索引it1c1c2(c1,c2)，查询语句select * from t1 where c1=1 and c2=2能够使用该索引。查询语句select * from t1 where c1=1也能够使用该索引。但是，查询语句select * from t1 where c2=2不能够使用该索引，因为没有组合索引的引导列，即，要想使用c2列进行查找，必需出现c1等于某值。

2.1、索引的类型
索引是在存储引擎中实现的，而不是在服务器层中实现的。所以，每种存储引擎的索引都不一定完全相同，并不是所有的存储引擎都支持所有的索引类型。
2.1.1、B-Tree索引
假设有如下一个表：
CREATE TABLE People (
last_name varchar(50) not null,
first_name varchar(50) not null,
dob date not null,
gender enum('m', 'f') not null,
key(last_name, first_name, dob)
);
其索引包含表中每一行的last_name、first_name和dob列。其结构大致如下：

索引存储的值按索引列中的顺序排列。可以利用B-Tree索引进行全关键字、关键字范围和关键字前缀查询，当然，如果想使用索引，你必须保证按索引的最左边前缀(leftmost prefix of the index)来进行查询。
(1)匹配全值(Match the full value)：对索引中的所有列都指定具体的值。例如，上图中索引可以帮助你查找出生于1960-01-01的Cuba Allen。
(2)匹配最左前缀(Match a leftmost prefix)：你可以利用索引查找last name为Allen的人，仅仅使用索引中的第1列。
(3)匹配列前缀(Match a column prefix)：例如，你可以利用索引查找last name以J开始的人，这仅仅使用索引中的第1列。
(4)匹配值的范围查询(Match a range of values)：可以利用索引查找last name在Allen和Barrymore之间的人，仅仅使用索引中第1列。
(5)匹配部分精确而其它部分进行范围匹配(Match one part exactly and match a range on another part)：可以利用索引查找last name为Allen，而first name以字母K开始的人。
(6)仅对索引进行查询(Index-only queries)：如果查询的列都位于索引中，则不需要读取元组的值。
由于B-树中的节点都是顺序存储的，所以可以利用索引进行查找(找某些值)，也可以对查询结果进行ORDER BY。当然，使用B-tree索引有以下一些限制：
(1) 查询必须从索引的最左边的列开始。关于这点已经提了很多遍了。例如你不能利用索引查找在某一天出生的人。
(2) 不能跳过某一索引列。例如，你不能利用索引查找last name为Smith且出生于某一天的人。
(3) 存储引擎不能使用索引中范围条件右边的列。例如，如果你的查询语句为WHERE last_name="Smith" AND first_name LIKE 'J%' AND dob='1976-12-23'，则该查询只会使用索引中的前两列，因为LIKE是范围查询。

2.1.2、Hash索引
MySQL中，只有Memory存储引擎显示支持hash索引，是Memory表的默认索引类型，尽管Memory表也可以使用B-Tree索引。Memory存储引擎支持非唯一hash索引，这在数据库领域是罕见的，如果多个值有相同的hash code，索引把它们的行指针用链表保存到同一个hash表项中。
假设创建如下一个表：
CREATE TABLE testhash (
fname VARCHAR(50) NOT NULL,
lname VARCHAR(50) NOT NULL,
KEY USING HASH(fname)
) ENGINE=MEMORY;
包含的数据如下：

假设索引使用hash函数f( )，如下：
f('Arjen') = 2323
f('Baron') = 7437
f('Peter') = 8784
f('Vadim') = 2458
此时，索引的结构大概如下：

Slots是有序的，但是记录不是有序的。当你执行
mysql> SELECT lname FROM testhash WHERE fname='Peter';
MySQL会计算’Peter’的hash值，然后通过它来查询索引的行指针。因为f('Peter') = 8784，MySQL会在索引中查找8784，得到指向记录3的指针。
因为索引自己仅仅存储很短的值，所以，索引非常紧凑。Hash值不取决于列的数据类型，一个TINYINT列的索引与一个长字符串列的索引一样大。

Hash索引有以下一些限制：
(1)由于索引仅包含hash code和记录指针，所以，MySQL不能通过使用索引避免读取记录。但是访问内存中的记录是非常迅速的，不会对性造成太大的影响。
(2)不能使用hash索引排序。
(3)Hash索引不支持键的部分匹配，因为是通过整个索引值来计算hash值的。
(4)Hash索引只支持等值比较，例如使用=，IN( )和<=>。对于WHERE price>100并不能加速查询。
2.1.3、空间(R-Tree)索引
MyISAM支持空间索引，主要用于地理空间数据类型，例如GEOMETRY。
2.1.4、全文(Full-text)索引
全文索引是MyISAM的一个特殊索引类型，主要用于全文检索。

3、高性能的索引策略
3.1、聚簇索引(Clustered Indexes)
聚簇索引保证关键字的值相近的元组存储的物理位置也相同（所以字符串类型不宜建立聚簇索引，特别是随机字符串，会使得系统进行大量的移动操作），且一个表只能有一个聚簇索引。因为由存储引擎实现索引，所以，并不是所有的引擎都支持聚簇索引。目前，只有solidDB和InnoDB支持。
聚簇索引的结构大致如下：

注：叶子页面包含完整的元组，而内节点页面仅包含索引的列(索引的列为整型)。一些DBMS允许用户指定聚簇索引，但是MySQL的存储引擎到目前为止都不支持。InnoDB对主键建立聚簇索引。如果你不指定主键，InnoDB会用一个具有唯一且非空值的索引来代替。如果不存在这样的索引，InnoDB会定义一个隐藏的主键，然后对其建立聚簇索引。一般来说，DBMS都会以聚簇索引的形式来存储实际的数据，它是其它二级索引的基础。
3.1.1、InnoDB和MyISAM的数据布局的比较
为了更加理解聚簇索引和非聚簇索引，或者primary索引和second索引(MyISAM不支持聚簇索引)，来比较一下InnoDB和MyISAM的数据布局，对于如下表：

CREATE TABLE layout_test (
col1 int NOT NULL,
col2 int NOT NULL,
PRIMARY KEY(col1),
KEY(col2)
);
假设主键的值位于1---10,000之间，且按随机顺序插入，然后用OPTIMIZE TABLE进行优化。col2随机赋予1---100之间的值，所以会存在许多重复的值。
(1) MyISAM的数据布局
其布局十分简单，MyISAM按照插入的顺序在磁盘上存储数据，如下：

注：左边为行号(row number)，从0开始。因为元组的大小固定，所以MyISAM可以很容易的从表的开始位置找到某一字节的位置。
据些建立的primary key的索引结构大致如下：

注：MyISAM不支持聚簇索引，索引中每一个叶子节点仅仅包含行号(row number)，且叶子节点按照col1的顺序存储。
来看看col2的索引结构：

实际上，在MyISAM中，primary key和其它索引没有什么区别。Primary key仅仅只是一个叫做PRIMARY的唯一，非空的索引而已。

(2) InnoDB的数据布局
InnoDB按聚簇索引的形式存储数据，所以它的数据布局有着很大的不同。它存储表的结构大致如下：

注：聚簇索引中的每个叶子节点包含primary key的值，事务ID和回滚指针(rollback pointer)——用于事务和MVCC，和余下的列(如col2)。

相对于MyISAM，二级索引与聚簇索引有很大的不同。InnoDB的二级索引的叶子包含primary key的值，而不是行指针(row pointers)，这减小了移动数据或者数据页面分裂时维护二级索引的开销，因为InnoDB不需要更新索引的行指针。其结构大致如下：

聚簇索引和非聚簇索引表的对比：

3.1.2、按primary key的顺序插入行(InnoDB)
如果你用InnoDB，而且不需要特殊的聚簇索引，一个好的做法就是使用代理主键(surrogate key)——独立于你的应用中的数据。最简单的做法就是使用一个AUTO_INCREMENT的列，这会保证记录按照顺序插入，而且能提高使用primary key进行连接的查询的性能。应该尽量避免随机的聚簇主键，例如，字符串主键就是一个不好的选择，它使得插入操作变得随机。

3.2、覆盖索引(Covering Indexes)
如果索引包含满足查询的所有数据，就称为覆盖索引。覆盖索引是一种非常强大的工具，能大大提高查询性能。只需要读取索引而不用读取数据有以下一些优点：
(1)索引项通常比记录要小，所以MySQL访问更少的数据；
(2)索引都按值的大小顺序存储，相对于随机访问记录，需要更少的I/O；
(3)大多数据引擎能更好的缓存索引。比如MyISAM只缓存索引。
(4)覆盖索引对于InnoDB表尤其有用，因为InnoDB使用聚集索引组织数据，如果二级索引中包含查询所需的数据，就不再需要在聚集索引中查找了。
覆盖索引不能是任何索引，只有B-TREE索引存储相应的值。而且不同的存储引擎实现覆盖索引的方式都不同，并不是所有存储引擎都支持覆盖索引(Memory和Falcon就不支持)。
对于索引覆盖查询(index-covered query)，使用EXPLAIN时，可以在Extra一列中看到“Using index”。例如，在sakila的inventory表中，有一个组合索引(store_id,film_id)，对于只需要访问这两列的查询，MySQL就可以使用索引，如下：
mysql> EXPLAIN SELECT store_id, film_id FROM sakila.inventory\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: inventory
type: index
possible_keys: NULL
key: idx_store_id_film_id
key_len: 3
ref: NULL
rows: 5007
Extra: Using index
1 row in set (0.17 sec)
在大多数引擎中，只有当查询语句所访问的列是索引的一部分时，索引才会覆盖。但是，InnoDB不限于此，InnoDB的二级索引在叶子节点中存储了primary key的值。因此，sakila.actor表使用InnoDB，而且对于是last_name上有索引，所以，索引能覆盖那些访问actor_id的查询，如：

mysql> EXPLAIN SELECT actor_id, last_name
-> FROM sakila.actor WHERE last_name = 'HOPPER'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: actor
type: ref
possible_keys: idx_actor_last_name
key: idx_actor_last_name
key_len: 137
ref: const
rows: 2
Extra: Using where; Using index

3.3、利用索引进行排序
MySQL中，有两种方式生成有序结果集：一是使用filesort，二是按索引顺序扫描。利用索引进行排序操作是非常快的，而且可以利用同一索引同时进行查找和排序操作。当索引的顺序与ORDER BY中的列顺序相同且所有的列是同一方向(全部升序或者全部降序)时，可以使用索引来排序。如果查询是连接多个表，仅当ORDER BY中的所有列都是第一个表的列时才会使用索引。其它情况都会使用filesort。
create table actor(
actor_id int unsigned NOT NULL AUTO_INCREMENT,
name varchar(16) NOT NULL DEFAULT '',
password varchar(16) NOT NULL DEFAULT '',
PRIMARY KEY(actor_id),
KEY (name)
) ENGINE=InnoDB
insert into actor(name,password) values('cat01','1234567');
insert into actor(name,password) values('cat02','1234567');
insert into actor(name,password) values('ddddd','1234567');
insert into actor(name,password) values('aaaaa','1234567');

mysql> explain select actor_id from actor order by actor_id \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: actor
type: index
possible_keys: NULL
key: PRIMARY
key_len: 4
ref: NULL
rows: 4
Extra: Using index
1 row in set (0.00 sec)

mysql> explain select actor_id from actor order by password \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: actor
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4
Extra: Using filesort
1 row in set (0.00 sec)

mysql> explain select actor_id from actor order by name \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: actor
type: index
possible_keys: NULL
key: name
key_len: 18
ref: NULL
rows: 4
Extra: Using index
1 row in set (0.00 sec)
当MySQL不能使用索引进行排序时，就会利用自己的排序算法(快速排序算法)在内存(sort buffer)中对数据进行排序，如果内存装载不下，它会将磁盘上的数据进行分块，再对各个数据块进行排序，然后将各个块合并成有序的结果集（实际上就是外排序）。对于filesort，MySQL有两种排序算法。
(1)两遍扫描算法(Two passes)
实现方式是先将须要排序的字段和可以直接定位到相关行数据的指针信息取出，然后在设定的内存（通过参数sort_buffer_size设定）中进行排序，完成排序之后再次通过行指针信息取出所需的Columns。
注：该算法是4.1之前采用的算法，它需要两次访问数据，尤其是第二次读取操作会导致大量的随机I/O操作。另一方面，内存开销较小。
(3) 一次扫描算法(single pass)
该算法一次性将所需的Columns全部取出，在内存中排序后直接将结果输出。
注：从 MySQL 4.1 版本开始使用该算法。它减少了I/O的次数，效率较高，但是内存开销也较大。如果我们将并不需要的Columns也取出来，就会极大地浪费排序过程所需要的内存。在 MySQL 4.1 之后的版本中，可以通过设置 max_length_for_sort_data 参数来控制 MySQL 选择第一种排序算法还是第二种。当取出的所有大字段总大小大于 max_length_for_sort_data 的设置时，MySQL 就会选择使用第一种排序算法，反之，则会选择第二种。为了尽可能地提高排序性能，我们自然更希望使用第二种排序算法，所以在 Query 中仅仅取出需要的 Columns 是非常有必要的。

当对连接操作进行排序时，如果ORDER BY仅仅引用第一个表的列，MySQL对该表进行filesort操作，然后进行连接处理，此时，EXPLAIN输出“Using filesort”；否则，MySQL必须将查询的结果集生成一个临时表，在连接完成之后进行filesort操作，此时，EXPLAIN输出“Using temporary;Using filesort”。

3.4、索引与加锁
索引对于InnoDB非常重要，因为它可以让查询锁更少的元组。这点十分重要，因为MySQL 5.0中，InnoDB直到事务提交时才会解锁。有两个方面的原因：首先，即使InnoDB行级锁的开销非常高效，内存开销也较小，但不管怎么样，还是存在开销。其次，对不需要的元组的加锁，会增加锁的开销，降低并发性。
InnoDB仅对需要访问的元组加锁，而索引能够减少InnoDB访问的元组数。但是，只有在存储引擎层过滤掉那些不需要的数据才能达到这种目的。一旦索引不允许InnoDB那样做（即达不到过滤的目的），MySQL服务器只能对InnoDB返回的数据进行WHERE操作，此时，已经无法避免对那些元组加锁了：InnoDB已经锁住那些元组，服务器无法解锁了。
来看个例子：
create table actor(
actor_id int unsigned NOT NULL AUTO_INCREMENT,
name varchar(16) NOT NULL DEFAULT '',
password varchar(16) NOT NULL DEFAULT '',
PRIMARY KEY(actor_id),
KEY (name)
) ENGINE=InnoDB
insert into actor(name,password) values('cat01','1234567');
insert into actor(name,password) values('cat02','1234567');
insert into actor(name,password) values('ddddd','1234567');
insert into actor(name,password) values('aaaaa','1234567');
SET AUTOCOMMIT=0;
BEGIN;
SELECT actor_id FROM actor WHERE actor_id < 4
AND actor_id <> 1 FOR UPDATE;
该查询仅仅返回2---3的数据，实际已经对1---3的数据加上排它锁了。InnoDB锁住元组1是因为MySQL的查询计划仅使用索引进行范围查询（而没有进行过滤操作，WHERE中第二个条件已经无法使用索引了）：

mysql> EXPLAIN SELECT actor_id FROM test.actor
-> WHERE actor_id < 4 AND actor_id <> 1 FOR UPDATE \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: actor
type: index
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: NULL
rows: 4
Extra: Using where; Using index
1 row in set (0.00 sec)

mysql>
表明存储引擎从索引的起始处开始，获取所有的行，直到actor_id<4为假，服务器无法告诉InnoDB去掉元组1。
为了证明row 1已经被锁住，我们另外建一个连接，执行如下操作：
SET AUTOCOMMIT=0;
BEGIN;
SELECT actor_id FROM actor WHERE actor_id = 1 FOR UPDATE;

该查询会被挂起，直到第一个连接的事务提交释放锁时，才会执行（这种行为对于基于语句的复制(statement-based replication)是必要的）。
如上所示，当使用索引时，InnoDB会锁住它不需要的元组。更糟糕的是，如果查询不能使用索引，MySQL会进行全表扫描，并锁住每一个元组，不管是否真正需要。

MySQL索引分析和优化转

825211@qq.com( 黑鹰) — Mon, 09 Nov 2009 14:52:43 GMT

一、什么是索引？索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。
假设我们创建了一个名为people的表：
CREATE TABLE people ( peopleid SMALLINT NOT NULL, name CHAR(50) NOT NULL );
然后，我们完全随机把1000个不同name值插入到people表。下图显示了people表所在数据文件的一小部分：

可以看到，在数据文件中name列没有任何明确的次序。如果我们创建了name列的索引，MySQL将在索引中排序name列：

对于索引中的每一项，MySQL在内部为它保存一个数据文件中实际记录所在位置的“指针”。因此，如果我们要查找name等于“Mike”记录的peopleid（SQL命令为“SELECT peopleid FROM people WHERE name=\'Mike\';”），MySQL能够在name的索引中查找“Mike”值，然后直接转到数据文件中相应的行，准确地返回该行的peopleid（999）。在这个过程中，MySQL只需处理一个行就可以返回结果。如果没有“name”列的索引，MySQL要扫描数据文件中的所有记录，即1000个记录！显然，需要MySQL处理的记录数量越少，则它完成任务的速度就越快。
[编辑]
二、索引的类型MySQL提供多种索引类型供选择：

普通索引

这是最基本的索引类型，而且它没有唯一性之类的限制。普通索引可以通过以下几种方式创建：创建索引，例如CREATE INDEX <索引的名字> ON tablename (列的列表); 修改表，例如ALTER TABLE tablename ADD INDEX [索引的名字] (列的列表); 创建表的时候指定索引，例如CREATE TABLE tablename ( [...], INDEX [索引的名字] (列的列表) );

唯一性索引

这种索引和前面的“普通索引”基本相同，但有一个区别：索引列的所有值都只能出现一次，即必须唯一。唯一性索引可以用以下几种方式创建：创建索引，例如CREATE UNIQUE INDEX <索引的名字> ON tablename (列的列表); 修改表，例如ALTER TABLE tablename ADD UNIQUE [索引的名字] (列的列表); 创建表的时候指定索引，例如CREATE TABLE tablename ( [...], UNIQUE [索引的名字] (列的列表) );

主键

主键是一种唯一性索引，但它必须指定为“PRIMARY KEY”。如果你曾经用过AUTO_INCREMENT类型的列，你可能已经熟悉主键之类的概念了。主键一般在创建表的时候指定，例如“CREATE TABLE tablename ( [...], PRIMARY KEY (列的列表) ); ”。但是，我们也可以通过修改表的方式加入主键，例如“ALTER TABLE tablename ADD PRIMARY KEY (列的列表); ”。每个表只能有一个主键。

全文索引

MySQL从3.23.23版开始支持全文索引和全文检索。在MySQL中，全文索引的索引类型为FULLTEXT。全文索引可以在VARCHAR或者TEXT类型的列上创建。它可以通过CREATE TABLE命令创建，也可以通过ALTER TABLE或CREATE INDEX命令创建。对于大规模的数据集，通过ALTER TABLE（或者CREATE INDEX）命令创建全文索引要比把记录插入带有全文索引的空表更快。本文下面的讨论不再涉及全文索引，要了解更多信息，请参见MySQL documentation。

[编辑]
三、单列索引与多列索引索引可以是单列索引，也可以是多列索引。下面我们通过具体的例子来说明这两种索引的区别。假设有这样一个people表：

这个数据片段中有四个名字为“Mikes”的人（其中两个姓Sullivans，两个姓McConnells），有两个年龄为17岁的人，还有一个名字与众不同的Joe Smith。
这个表的主要用途是根据指定的用户姓、名以及年龄返回相应的peopleid。例如，我们可能需要查找姓名为Mike Sullivan、年龄17岁用户的peopleid（SQL命令为SELECT peopleid FROM people WHERE firstname=\'Mike\' AND lastname=\'Sullivan\' AND age=17;）。由于我们不想让MySQL每次执行查询就去扫描整个表，这里需要考虑运用索引。
首先，我们可以考虑在单个列上创建索引，比如firstname、lastname或者age列。如果我们创建firstname列的索引（ALTER TABLE people ADD INDEX firstname (firstname);），MySQL将通过这个索引迅速把搜索范围限制到那些firstname=\'Mike\'的记录，然后再在这个“中间结果集”上进行其他条件的搜索：它首先排除那些lastname不等于“Sullivan”的记录，然后排除那些age不等于17的记录。当记录满足所有搜索条件之后，MySQL就返回最终的搜索结果。
由于建立了firstname列的索引，与执行表的完全扫描相比，MySQL的效率提高了很多，但我们要求MySQL扫描的记录数量仍旧远远超过了实际所需要的。虽然我们可以删除firstname列上的索引，再创建lastname或者age列的索引，但总地看来，不论在哪个列上创建索引搜索效率仍旧相似。
为了提高搜索效率，我们需要考虑运用多列索引。如果为firstname、lastname和age这三个列创建一个多列索引，MySQL只需一次检索就能够找出正确的结果！下面是创建这个多列索引的SQL命令：

ALTER TABLE people ADD INDEX fname_lname_age (firstname,lastname,age);
由于索引文件以B-树格式保存，MySQL能够立即转到合适的firstname，然后再转到合适的lastname，最后转到合适的age。在没有扫描数据文件任何一个记录的情况下，MySQL就正确地找出了搜索的目标记录！
那么，如果在firstname、lastname、age这三个列上分别创建单列索引，效果是否和创建一个firstname、lastname、age的多列索引一样呢？答案是否定的，两者完全不同。当我们执行查询的时候，MySQL只能使用一个索引。如果你有三个单列的索引，MySQL会试图选择一个限制最严格的索引。但是，即使是限制最严格的单列索引，它的限制能力也肯定远远低于firstname、lastname、age这三个列上的多列索引。
[编辑]
四、最左前缀多列索引还有另外一个优点，它通过称为最左前缀（Leftmost Prefixing）的概念体现出来。继续考虑前面的例子，现在我们有一个firstname、lastname、age列上的多列索引，我们称这个索引为fname_lname_age。当搜索条件是以下各种列的组合时，MySQL将使用fname_lname_age索引：

firstname，lastname，age firstname，lastname firstname 从另一方面理解，它相当于我们创建了(firstname，lastname，age)、(firstname，lastname)以及(firstname)这些列组合上的索引。下面这些查询都能够使用这个fname_lname_age索引：

MySQL文档找到有关该命令的更多说明。下面是一个例子：

table type possible_keys key key_len ref rows Extra people ref fname_lname_age fname_lname_age 102 const,const,const 1 Where used 下面我们就来看看这个EXPLAIN分析结果的含义。

table：这是表的名字。 type：连接操作的类型。下面是MySQL文档关于ref连接类型的说明：
“对于每一种与另一个表中记录的组合，MySQL将从当前的表读取所有带有匹配索引值的记录。如果连接操作只使用键的最左前缀，或者如果键不是UNIQUE或PRIMARY KEY类型（换句话说，如果连接操作不能根据键值选择出唯一行），则MySQL使用ref连接类型。如果连接操作所用的键只匹配少量的记录，则ref是一种好的连接类型。”
在本例中，由于索引不是UNIQUE类型，ref是我们能够得到的最好连接类型。
如果EXPLAIN显示连接类型是“ALL”，而且你并不想从表里面选择出大多数记录，那么MySQL的操作效率将非常低，因为它要扫描整个表。你可以加入更多的索引来解决这个问题。预知更多信息，请参见MySQL的手册说明。 possible_keys：可能可以利用的索引的名字。这里的索引名字是创建索引时指定的索引昵称；如果索引没有昵称，则默认显示的是索引中第一个列的名字（在本例中，它是“firstname”）。默认索引名字的含义往往不是很明显。 Key：它显示了MySQL实际使用的索引的名字。如果它为空（或NULL），则MySQL不使用索引。 key_len：索引中被使用部分的长度，以字节计。在本例中，key_len是102，其中firstname占50字节，lastname占50字节，age占2字节。如果MySQL只使用索引中的firstname部分，则key_len将是50。 ref：它显示的是列的名字（或单词“const”），MySQL将根据这些列来选择行。在本例中，MySQL根据三个常量选择行。 rows： MySQL所认为的它在找到正确的结果之前必须扫描的记录数。显然，这里最理想的数字就是1。 Extra：这里可能出现许多不同的选项，其中大多数将对查询产生负面影响。在本例中，MySQL只是提醒我们它将用WHERE子句限制搜索结果集。
[编辑]
七、索引的缺点到目前为止，我们讨论的都是索引的优点。事实上，索引也是有缺点的。
首先，索引要占用磁盘空间。通常情况下，这个问题不是很突出。但是，如果你创建每一种可能列组合的索引，索引文件体积的增长速度将远远超过数据文件。如果你有一个很大的表，索引文件的大小可能达到操作系统允许的最大文件限制。
第二，对于需要写入数据的操作，比如DELETE、UPDATE以及INSERT操作，索引会降低它们的速度。这是因为MySQL不仅要把改动数据写入数据文件，而且它还要把这些改动写入索引文件。
【结束语】在大型数据库中，索引是提高速度的一个关键因素。不管表的结构是多么简单，一次500000行的表扫描操作无论如何不会快。如果你的网站上也有这种大规模的表，那么你确实应该花些时间去分析可以采用哪些索引，并考虑是否可以改写查询以优化应用。要了解更多信息，请参见MySQL manual。另外注意，本文假定你所使用的MySQL是3.23版，部分查询不能在3.22版MySQL上执行。
取自"http://know.chinabyte.com/index.php/MySQL%E7%B4%A2%E5%BC%95%E5%88%86%E6%9E%90%E5%92%8C%E4%BC%98%E5%8C%96"

mysql InnoDB行锁的实现例子分析

825211@qq.com( 黑鹰) — Mon, 09 Nov 2009 14:42:53 GMT

InnoDB行锁是通过给索引上的索引项加锁来实现的，这一点MySQL与Oracle不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁！
在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突，从而影响并发性能。下面通过一些实际例子来加以说明。
（1）在不通过索引条件查询的时候，InnoDB确实使用的是表锁，而不是行锁。
在如表20-9所示的例子中，开始tab_no_index表没有索引：

mysql> create table tab_no_index(id int,name varchar(10)) engine=innodb;Query OK, 0 rows affected (0.15 sec)
mysql> insert into tab_no_index values(1,'1'),(2,'2'),(3,'3'),(4,'4');Query OK, 4 rows affected (0.00 sec)Records: 4 Duplicates: 0 Warnings: 0
表20-9 InnoDB存储引擎的表在不使用索引时使用表锁例子

session_1
session_2
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_no_index where id = 1 ;
+------+------+
| id | name |
+------+------+
| 1 | 1 |
+------+------+
1 row in set (0.00 sec)
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_no_index where id = 2 ;
+------+------+
| id | name |
+------+------+
| 2 | 2 |
+------+------+
1 row in set (0.00 sec)
mysql> select * from tab_no_index where id = 1 for update;
+------+------+
| id | name |
+------+------+
| 1 | 1 |
+------+------+
1 row in set (0.00 sec)

mysql> select * from tab_no_index where id = 2 for update;
等待
在如表20-9所示的例子中，看起来session_1只给一行加了排他锁，但session_2在请求其他行的排他锁时，却出现了锁等待！原因就是在没有索引的情况下，InnoDB只能使用表锁。当我们给其增加一个索引后，InnoDB就只锁定了符合条件的行，如表20-10所示。
创建tab_with_index表，id字段有普通索引：

mysql> create table tab_with_index(id int,name varchar(10)) engine=innodb;Query OK, 0 rows affected (0.15 sec)mysql> alter table tab_with_index add index id(id);Query OK, 4 rows affected (0.24 sec)Records: 4 Duplicates: 0 Warnings: 0
表20-10 InnoDB存储引擎的表在使用索引时使用行锁例子

session_1
session_2
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_with_index where id = 1 ;
+------+------+
| id | name |
+------+------+
| 1 | 1 |
+------+------+
1 row in set (0.00 sec)
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_with_index where id = 2 ;
+------+------+
| id | name |
+------+------+
| 2 | 2 |
+------+------+
1 row in set (0.00 sec)
mysql> select * from tab_with_index where id = 1 for update;
+------+------+
| id | name |
+------+------+
| 1 | 1 |
+------+------+
1 row in set (0.00 sec)

mysql> select * from tab_with_index where id = 2 for update;
+------+------+
| id | name |
+------+------+
| 2 | 2 |
+------+------+
1 row in set (0.00 sec)
（2）由于MySQL的行锁是针对索引加的锁，不是针对记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的。应用设计的时候要注意这一点。
在如表20-11所示的例子中，表tab_with_index的id字段有索引，name字段没有索引：

mysql> alter table tab_with_index drop index name;Query OK, 4 rows affected (0.22 sec)Records: 4 Duplicates: 0 Warnings: 0
mysql> insert into tab_with_index values(1,'4');Query OK, 1 row affected (0.00 sec)
mysql> select * from tab_with_index where id = 1;+------+------+| id | name |+------+------+| 1 | 1 || 1 | 4 |+------+------+2 rows in set (0.00 sec)
表20-11 InnoDB存储引擎使用相同索引键的阻塞例子

session_1
session_2
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_with_index where id = 1 and name = '1' for update;
+------+------+
| id | name |
+------+------+
| 1 | 1 |
+------+------+
1 row in set (0.00 sec)

虽然session_2访问的是和session_1不同的记录，但是因为使用了相同的索引，所以需要等待锁：
mysql> select * from tab_with_index where id = 1 and name = '4' for update;
等待
（3）当表有多个索引的时候，不同的事务可以使用不同的索引锁定不同的行，另外，不论是使用主键索引、唯一索引或普通索引，InnoDB都会使用行锁来对数据加锁。
在如表20-12所示的例子中，表tab_with_index的id字段有主键索引，name字段有普通索引：

mysql> alter table tab_with_index add index name(name);Query OK, 5 rows affected (0.23 sec)Records: 5 Duplicates: 0 Warnings: 0
表20-12 InnoDB存储引擎的表使用不同索引的阻塞例子

· session_1
· session_2
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_with_index where id = 1 for update;
+------+------+
| id | name |
+------+------+
| 1 | 1 |
| 1 | 4 |
+------+------+
2 rows in set (0.00 sec)

Session_2使用name的索引访问记录，因为记录没有被索引，所以可以获得锁：
mysql> select * from tab_with_index where name = '2' for update;
+------+------+
| id | name |
+------+------+
| 2 | 2 |
+------+------+
1 row in set (0.00 sec)

由于访问的记录已经被session_1锁定，所以等待获得锁。：
mysql> select * from tab_with_index where name = '4' for update;
（4）即便在条件中使用了索引字段，但是否使用索引来检索数据是由MySQL通过判断不同执行计划的代价来决定的，如果MySQL认为全表扫描效率更高，比如对一些很小的表，它就不会使用索引，这种情况下InnoDB将使用表锁，而不是行锁。因此，在分析锁冲突时，别忘了检查SQL的执行计划，以确认是否真正使用了索引。关于MySQL在什么情况下不使用索引的详细讨论，参见本章“索引问题”一节的介绍。
在下面的例子中，检索值的数据类型与索引字段不同，虽然MySQL能够进行数据类型转换，但却不会使用索引，从而导致InnoDB使用表锁。通过用explain检查两条SQL的执行计划，我们可以清楚地看到了这一点。
例子中tab_with_index表的name字段有索引，但是name字段是varchar类型的，如果where条件中不是和varchar类型进行比较，则会对name进行类型转换，而执行的全表扫描。

mysql> alter table tab_no_index add index name(name);Query OK, 4 rows affected (8.06 sec)Records: 4 Duplicates: 0 Warnings: 0
mysql> explain select * from tab_with_index where name = 1 \G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: tab_with_indextype: ALLpossible_keys: namekey: NULLkey_len: NULLref: NULLrows: 4Extra: Using where1 row in set (0.00 sec)mysql> explain select * from tab_with_index where name = '1' \G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: tab_with_indextype: refpossible_keys: namekey: namekey_len: 23ref: constrows: 1Extra: Using where1 row in set (0.00 sec)

当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（Next-Key 锁）。
举例来说，假如emp表中只有101条记录，其empid的值分别是 1,2,...,100,101，下面的SQL：

Select * from emp where empid > 100 for update;
是一个范围条件的检索，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的“间隙”加锁。
InnoDB使用间隙锁的目的，一方面是为了防止幻读，以满足相关隔离级别的要求，对于上面的例子，要是不使用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；另外一方面，是为了满足其恢复和复制的需要。有关其恢复和复制对锁机制的影响，以及不同隔离级别下InnoDB使用间隙锁的情况，在后续的章节中会做进一步介绍。
很显然，在使用范围条件检索并锁定记录时，InnoDB这种加锁机制会阻塞符合条件范围内键值的并发插入，这往往会造成严重的锁等待。因此，在实际应用开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。
还要特别说明的是，InnoDB除了通过范围条件加锁时使用间隙锁外，如果使用相等条件请求给一个不存在的记录加锁，InnoDB也会使用间隙锁！
在如表20-13所示的例子中，假如emp表中只有101条记录，其empid的值分别是1,2,......,100,101。
表20-13 InnoDB存储引擎的间隙锁阻塞例子

session_1
session_2
mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set (0.00 sec)

mysql> set autocommit = 0;
Query OK, 0 rows affected (0.00 sec)
mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set (0.00 sec)

mysql> set autocommit = 0;
Query OK, 0 rows affected (0.00 sec)
当前session对不存在的记录加for update的锁：
mysql> select * from emp where empid = 102 for update;
Empty set (0.00 sec)

这时，如果其他session插入empid为201的记录（注意：这条记录并不存在），也会出现锁等待：
mysql>insert into emp(empid,...) values(201,...);
阻塞等待
Session_1 执行rollback：
mysql> rollback;
Query OK, 0 rows affected (13.04 sec)

由于其他session_1回退后释放了Next-Key锁，当前session可以获得锁并成功插入记录：
mysql>insert into emp(empid,...) values(201,...);
Query OK, 1 row affected (13.35 sec)

偷拍崔泰宇

825211@qq.com( 黑鹰) — Sat, 07 Nov 2009 07:52:59 GMT

金宝贝

[转]2009-11-1 荔香公园-球

825211@qq.com( 黑鹰) — Sun, 01 Nov 2009 13:56:58 GMT

今天去荔香公园，主要是玩球，自己带一球先，到公园和别人换更好看的玩，嘿嘿。

照片名称：朝着荔香公园go

照片名称：摔倒了，爬起来

照片名称：我喜欢这条路

照片名称：nEO_IMG_IMG_61

照片名称：我是一只小小小小鸟

照片名称：nEO_IMG_IMG_61

照片名称：妈妈你终于来了

照片名称：nEO_IMG_IMG_61

照片名称：nEO_IMG_IMG_61

看到小姐姐在玩羽毛球，借过来玩会儿先

照片名称：nEO_IMG_IMG_61

照片名称：nEO_IMG_IMG_61

照片名称：nEO_IMG_IMG_61

照片名称：nEO_IMG_IMG_61

照片名称：球拍要这样握

照片名称：杀球
照片描述：看我动作标准不

照片名称：打球归来

照片名称：标准姿势

照片名称：快跑，接球

照片名称：爸爸，我要抱
照片描述：抱着爸爸的腿，露出可怜的眼神

照片名称：玩别人的车，嘘

最后去看了篮球，好多人在比赛，没有我玩的份，只能看了。

[转]2009国庆节山东之旅

825211@qq.com( 黑鹰) — Mon, 12 Oct 2009 13:22:09 GMT

照片名称：没见过帅哥啊？
照片描述：芙蓉楼

照片名称：这是我的
照片描述：好大的钱

照片名称：cindy姐姐
照片描述：姑奶奶家，teddy在睡觉

照片名称：天哪~

照片名称：车怎么还不来啊
照片描述：周村公共汽车站等车

照片名称：车怎么还不来啊
照片描述：周村公共汽车站等车

照片名称：客官，要买点啥

照片名称：我是小店主

照片名称：玉米，好玩
照片描述：这就是玉米，好玩

照片名称：玉米，好玩

照片名称：玉米，好玩

照片名称：cindy和teddy
照片描述：济南吉华大酒店

照片名称：地好滑啊~
照片描述：深圳机场

照片名称：好大的棒棒糖1
照片描述：深圳机场

泰宇11个月啦

825211@qq.com( 黑鹰) — Sun, 06 Sep 2009 12:09:37 GMT

[转]8月28日正式入住腾讯大厦

825211@qq.com( 黑鹰) — Fri, 28 Aug 2009 03:17:31 GMT

为了满足部分人的欲望，我也转一下：请欣赏
---------------------------------------------------------------------------------------------

8月28日正式入住腾讯大厦，转几张靓照！

转载：

这是咱们腾讯QQ其中的一个餐厅，艳艳的橙色，有二人餐桌，四人餐桌，酒吧台，还有两排8人桌，既可小聊，也可小小聚会，一字排开干净明亮


-------------------------------------老板层开始-------------------------------------

-------------------------------------老板层结束-------------------------------------

崔泰宇认识物品记录

825211@qq.com( 黑鹰) — Tue, 25 Aug 2009 14:37:42 GMT

今天把挂图拿出来，给泰宇认，
问泰宇：西瓜在哪里啊？
泰宇指着挂图上的西瓜:嗯~~嗯~~

哈哈，真开心，泰宇11个月就认识西瓜了
总结一下：
认识葡萄（最近天天吃）、西瓜、香蕉。（这是颜色类的）
认识圆形的篮球、环形的花环、五角星形的海星。（形状类的）

小家伙不错。学习东西挺快的。

仅此记录一下

黑鹰