非常简陋的一个PHP框架，只是把架子搭起来了，地址：http://code.google.com/p/colaphp/
现在PHP框架已经很多了，为什么还要去”重复的发明轮子”？
现在，ColaPHP还很不成熟，暂且当做一个”玩具”试试，有兴趣的可以阅读一下代码，品味好的代码和指出坏味道的代码都是一个好的过程。
文档方面现在还很不全，我希望只用一个Tutorial就能讲明白，以后也不会有别的新的文档（文档越多，表明系统越复杂，学习成本也越高），当然，Tutorial会是一个持续完善的过程。
ColaPHP是写给PHP程序员的一个框架，信奉KISS的同学可以试试。
断断续续的做了大半年歌曲相关性方面的试验，有一些肤浅的体会，工程方面多些，学术上仍很不足，与大家分享，望后来之君少走弯路，抑或被我带入岐途，不当之处，请指正。
PS：前段时间申请了个独立域名：http://www.fuchaoqun.com，烦请订阅feed者更新：http://www.fuchaoqun.com/feed/，原http://chaoqun.17348.com作了301跳转，将来一段时间内亦能访问。
Tags: KNN, recommender system, slope one, SVD
PERCONA PERFORMANCE CONFERENCE 2009上，来自雅虎的几位工程师带来了一篇”Efficient Pagination Using MySQL“的报告，有很多亮点，本文是在原文基础上的进一步延伸。
首先看一下分页的基本原理：
mysql> explain SELECT * FROM message ORDER BY id DESC LIMIT 10000, 20\G
***************** 1. row **************
id: 1
select_type: SIMPLE
table: message
type: index
possible_keys: NULL
key: PRIMARY
key_len: 4
ref: NULL
rows: 10020
Extra:
1 row in set (0.00 sec)
limit 10000,20的意思扫描满足条件的10020行，扔掉前面的10000行，返回最后的20行，问题就在这里，如果是limit 100000,100，需要扫描100100行，在一个高并发的应用里，每次查询需要扫描超过10W行，性能肯定大打折扣。文中还提到limit n性能是没问题的，因为只扫描n行。
文中提到一种”clue”的做法，给翻页提供一些”线索”，比如还是SELECT * FROM message ORDER BY id DESC，按id降序分页，每页20条，当前是第10页，当前页条目id最大的是9527，最小的是9500，如果我们只提供”上一页”、”下一页”这样的跳转（不提供到第N页的跳转），那么在处理”上一页”的时候SQL语句可以是：
SELECT * FROM message WHERE id > 9527 ORDER BY id ASC LIMIT 20;
处理”下一页”的时候SQL语句可以是：
SELECT * FROM message WHERE id < 9500 ORDER BY id DESC LIMIT 20;
不管翻多少页，每次查询只扫描20行。
缺点是只能提供”上一页”、”下一页”的链接形式，但是我们的产品经理非常喜欢”<上一页 1 2 3 4 5 6 7 8 9 下一页>”这样的链接方式，怎么办呢？
如果LIMIT m,n不可避免的话，要优化效率，只有尽可能的让m小一下，我们扩展前面的”clue”做法，还是SELECT * FROM message ORDER BY id DESC，按id降序分页，每页20条，当前是第10页，当前页条目id最大的是9527，最小的是9500，比如要跳到第8页，我看的SQL语句可以这样写：
SELECT * FROM message WHERE id > 9527 ORDER BY id ASC LIMIT 20,20;
跳转到第13页：
SELECT * FROM message WHERE id < 9500 ORDER BY id DESC LIMIT 40,20;
原理还是一样，记录住当前页id的最大值和最小值，计算跳转页面和当前页相对偏移，由于页面相近，这个偏移量不会很大，这样的话m值相对较小，大大减少扫描的行数。其实传统的limit m,n，相对的偏移一直是第一页，这样的话越翻到后面，效率越差，而上面给出的方法就没有这样的问题。
注意SQL语句里面的ASC和DESC，如果是ASC取出来的结果，显示的时候记得倒置一下。
已在60W数据总量的表中测试，效果非常明显。
Tags: MySQL, Performance
不知大家有没有发现，就算你选择了”记录登录状态”，下次访问kaixin001.com的时候还是官方静态首页，过一会才跳转到个人首页，这样的用户体验反正我是不太舒服，查看kaixin001首页源代码，发现个中蹊跷：
function _bodyonload() { .... var v_kx = getCookie('_kx'); if (v_kx.length) { .... v_timeid = setTimeout("gotohome()", 2000); } } function gotohome() { if (v_timeid) { window.location = "/home/?l=a"; } }
代码翻译成白话就是：页面加载完毕后，检测是否有’_kx’的cookie，如果有的话2秒后跳转到’/home/?l=a’页面，有的时候页面加载时间就很长，再等个两秒跳转，你都恨不得重新登录。
不知道kaixin001设计的时候是如何考虑的，从用户体验的角度来说：囧；从技术的角度来说：相当囧，仅仅是增加了服务器请求数（第一次请求首页白瞎），不知道kaixin001慢是不是这个原因，可能有更囧的。
很多时候我们会需要处理登录状态和非登录状态，一般可以在程序层面判断，比如PHP：
<?php if (empty($_COOKIE['_kx'])) { // 显示官方首页 }else { // 显示个人首页，记得校验cookie } ?>
kaixin001也是一个很大的SNS网站了，关于她的架构，未曾见诸网上，也许应该更开放一些，不过kaixin001网站整体的速度不太好，不知道是人太多、服务器太少，还是说存在伸展的问题。
用YSLOW测试了一下kaixin001″我的首页”，得分是F(49)，很多js没有压缩，js文件数有18个之多，css文件数5个，js文件放头部等等，同期测试豆瓣的”我的豆瓣”，得分C(79)，一直觉得douban的技术还是挺牛的，也比较开放。
Tags: kaixin001, Performance, YSLOW
最近几天，被pidgin折腾疯了，一会上线，一会自动退出，一会假死，看到好友发过来消息，可阅读不了具体内容，折腾的身心疲惫，升级到最新版本也无济于事。
由于在pidgin上登录了msn和gtalk帐号，初步怀疑是MSN插件的问题，貌似MSN之前升级了版本。禁用MSN帐号后，pidgin恢复稳定。
郁闷的不行了，找到一个第三方的MSN插件：http://code.google.com/p/msn-pecan/
wget http://msn-pecan.googlecode.com/files/msn-pecan-0.0.18.tar.bz2
tar xjf msn-pecan-0.0.18.tar.bz2 -C /usr/local/src
cd /usr/local/src/msn-pecan-0.0.18/
make
make install
安装之前记得安装libpurple-devel
yum install libpurple-devel
安装好了之后，pidgin中会出现WLM协议，用这个做MSN登录，世界总算清静下来了。
我这边是CentOS 5.3，Pidgin 2.5.5-1.el5，其他版本安装说明，阅读http://code.google.com/p/msn-pecan/wiki/HowToInstall
Web2.0网站，数据内容以几何级数增长，尤其是那些小文件，几K～几百K不等，数量巨多，传统的文件系统处理起来很是吃力，很多网站在scaling的过程中都遇到了这样的问题：磁盘IO过高；备份困难；单点问题，容量和读写无法水平扩展，还存在故障的可能。
YouTube也碰到这样的问题，每一个视频有4个缩微图，这样的话缩微图数量是视频数量的四倍，想象一下YouTube有多少视频，看一下他们遇到的问题：
YouTube的解决方案是Google的BigTable，一般人没戏。（原文参见：http://www.hfadeel.com/Blog/?p=127）
Facebook也遇到了同样的问题，他们的方案参见：http://www.dbanotes.net/arch/facebook_photos_arch.html，他们经历了三个阶段：
对于一般的网站来说，实用的方案有哪些呢？
一、NFS共享
是的，这个有很多问题，但实施成本低，很多公司都在用（我们也在用），在不是那么多文件，不是那么高并发的情况下还是很不错的，设置Hash目录，不要让一个目录下文件数过多，对于一般的网站来说足够用了。
备份确实是一个问题，如果不是海量的话，根据文件更新时间每天增量备份＋周期性的全量备份应该可以。
二、文件存数据库
真有人这么做，手机之家用MySQL建了256个表来存储超过1T的文件，前端加一个多级缓存（具体未知，也许就是memcached也许还是文件），数据库做数据备份用，他们用起来觉得还不错。
或者觉得MySQL太重，试试key->value的数据库，比如BDB，Tokyo Cabinet等。
三、分布式文件系统
开源的很多，好看簿用的是MogileFS，与memcached师出同门。傲游用MFS来存储用户的收藏夹文件，详细文章参见：分布式文件系统MFS(moosefs)实现存储共享(一) 、(二)，据说数百万轻松处理。
分布式文件系统好处是可以均衡读写压力，数据可靠性大大增加，某个数据节点挂了也没事。
还不行？自己DIY一个去吧，豆瓣就这么做的，TokyoCabinet做为底层存储，封装了一个memcached协议接口（与Tokyo Tyrant何异？），一致性哈希，应用程序根据哈希规则在node中读写数据:
DoubanFS结构图，版权由charlee所有
续根据status信息对MySQL服务器进行优化（一），直入主题。
六、进程使用情况
mysql> show global status like 'Thread%'; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | Threads_cached | 46 | | Threads_connected | 2 | | Threads_created | 570 | | Threads_running | 1 | +-------------------+-------+
如果我们在MySQL服务器配置文件中设置了thread_cache_size，当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁（前提是缓存数未达上限）。Threads_created表示创建过的线程数，如果发现Threads_created值过大的话，表明MySQL服务器一直在创建线程，这也是比较耗资源，可以适当增加配置文件中thread_cache_size值，查询服务器thread_cache_size配置：
mysql> show variables like 'thread_cache_size'; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | thread_cache_size | 64 | +-------------------+-------+
示例中的服务器还是挺健康的。
七、查询缓存(query cache)
mysql> show global status like 'qcache%'; +-------------------------+-----------+ | Variable_name | Value | +-------------------------+-----------+ | Qcache_free_blocks | 22756 | | Qcache_free_memory | 76764704 | | Qcache_hits | 213028692 | | Qcache_inserts | 208894227 | | Qcache_lowmem_prunes | 4010916 | | Qcache_not_cached | 13385031 | | Qcache_queries_in_cache | 43560 | | Qcache_total_blocks | 111212 | +-------------------------+-----------+
MySQL查询缓存变量解释：
Qcache_free_blocks：缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理，从而得到一个空闲块。
Qcache_free_memory：缓存中的空闲内存。
Qcache_hits：每次查询在缓存中命中时就增大
Qcache_inserts：每次插入一个查询时就增大。命中次数除以插入次数就是不中比率。
Qcache_lowmem_prunes：缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；如果这个数字在不断增长，就表示可能碎片非常严重，或者内存很少。（上面的 free_blocks和free_memory可以告诉您属于哪种情况）
Qcache_not_cached：不适合进行缓存的查询的数量，通常是由于这些查询不是SELECT语句或者用了now()之类的函数。
Qcache_queries_in_cache：当前缓存的查询（和响应）的数量。
Qcache_total_blocks：缓存中块的数量。
我们再查询一下服务器关于query_cache的配置：
mysql> show variables like 'query_cache%'; +------------------------------+-----------+ | Variable_name | Value | +------------------------------+-----------+ | query_cache_limit | 2097152 | | query_cache_min_res_unit | 4096 | | query_cache_size | 203423744 | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF | +------------------------------+-----------+
各字段的解释：
query_cache_limit：超过此大小的查询将不缓存
query_cache_min_res_unit：缓存块的最小大小
query_cache_size：查询缓存大小
query_cache_type：缓存类型，决定缓存什么样的查询，示例中表示不缓存 select sql_no_cache 查询
query_cache_wlock_invalidate：当有其他客户端正在对MyISAM表进行写操作时，如果查询在query cache中，是否返回cache结果还是等写操作完成再读表获取结果。
query_cache_min_res_unit的配置是一柄”双刃剑”，默认是4KB，设置值大对大数据查询有好处，但如果你的查询都是小数据查询，就容易造成内存碎片和浪费。
查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%
如果查询缓存碎片率超过20%，可以用FLUSH QUERY CACHE整理缓存碎片，或者试试减小query_cache_min_res_unit，如果你的查询都是小数据量的话。
查询缓存利用率 = (query_cache_size - Qcache_free_memory) / query_cache_size * 100%
查询缓存利用率在25%以下的话说明query_cache_size设置的过大，可适当减小；查询缓存利用率在80％以上而且Qcache_lowmem_prunes > 50的话说明query_cache_size可能有点小，要不就是碎片太多。
查询缓存命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%
示例服务器 查询缓存碎片率 ＝ 20.46％，查询缓存利用率 ＝ 62.26％，查询缓存命中率 ＝ 1.94％，命中率很差，可能写操作比较频繁吧，而且可能有些碎片。
八、排序使用情况
mysql> show global status like 'sort%'; +-------------------+------------+ | Variable_name | Value | +-------------------+------------+ | Sort_merge_passes | 29 | | Sort_range | 37432840 | | Sort_rows | 9178691532 | | Sort_scan | 1860569 | +-------------------+------------+
Sort_merge_passes 包括两步。MySQL 首先会尝试在内存中做排序，使用的内存大小由系统变量 Sort_buffer_size 决定，如果它的大小不够把所有的记录都读到内存中，MySQL 就会把每次在内存中排序的结果存到临时文件中，等 MySQL 找到所有记录之后，再把临时文件中的记录做一次排序。这再次排序就会增加 Sort_merge_passes。实际上，MySQL 会用另一个临时文件来存再次排序的结果，所以通常会看到 Sort_merge_passes 增加的数值是建临时文件数的两倍。因为用到了临时文件，所以速度可能会比较慢，增加 Sort_buffer_size 会减少 Sort_merge_passes 和 创建临时文件的次数。但盲目的增加 Sort_buffer_size 并不一定能提高速度，见 How fast can you sort data with MySQL?（引自http://qroom.blogspot.com/2007/09/mysql-select-sort.html，貌似被墙）
另外，增加read_rnd_buffer_size(3.2.3是record_rnd_buffer_size)的值对排序的操作也有一点的好处，参见：http://www.mysqlperformanceblog.com/2007/07/24/what-exactly-is-read_rnd_buffer_size/
九、文件打开数(open_files)
mysql> show global status like 'open_files'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Open_files | 1410 | +---------------+-------+ mysql> show variables like 'open_files_limit'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | open_files_limit | 4590 | +------------------+-------+
比较合适的设置：Open_files / open_files_limit * 100% <= 75％
十、表锁情况
mysql> show global status like 'table_locks%'; +-----------------------+-----------+ | Variable_name | Value | +-----------------------+-----------+ | Table_locks_immediate | 490206328 | | Table_locks_waited | 2084912 | +-----------------------+-----------+
Table_locks_immediate表示立即释放表锁数，Table_locks_waited表示需要等待的表锁数，如果Table_locks_immediate / Table_locks_waited > 5000，最好采用InnoDB引擎，因为InnoDB是行锁而MyISAM是表锁，对于高并发写入的应用InnoDB效果会好些。示例中的服务器Table_locks_immediate / Table_locks_waited ＝ 235，MyISAM就足够了。
十一、表扫描情况
mysql> show global status like 'handler_read%'; +-----------------------+-------------+ | Variable_name | Value | +-----------------------+-------------+ | Handler_read_first | 5803750 | | Handler_read_key | 6049319850 | | Handler_read_next | 94440908210 | | Handler_read_prev | 34822001724 | | Handler_read_rnd | 405482605 | | Handler_read_rnd_next | 18912877839 | +-----------------------+-------------+
各字段解释参见http://hi.baidu.com/thinkinginlamp/blog/item/31690cd7c4bc5cdaa144df9c.html，调出服务器完成的查询请求次数：
mysql> show global status like 'com_select'; +---------------+-----------+ | Variable_name | Value | +---------------+-----------+ | Com_select | 222693559 | +---------------+-----------+
计算表扫描率：
表扫描率 ＝ Handler_read_rnd_next / Com_select
如果表扫描率超过4000，说明进行了太多表扫描，很有可能索引没有建好，增加read_buffer_size值会有一些好处，但最好不要超过8MB。
后记：
文中提到一些数字都是参考值，了解基本原理就可以，除了MySQL提供的各种status值外，操作系统的一些性能指标也很重要，比如常用的top,iostat等，尤其是iostat，现在的系统瓶颈一般都在磁盘IO上，关于iostat的使用，可以参考：http://www.php-oa.com/2009/02/03/iostat.html
“根据status信息对MySQL服务器进行优化（一）、（二）”是最近学习MySQL status信息的读书笔记，谬讹之处，望请斧正。
网上有很多的文章教怎么配置MySQL服务器，但考虑到服务器硬件配置的不同，具体应用的差别，那些文章的做法只能作为初步设置参考，我们需要根据自己的情况进行配置优化，好的做法是MySQL服务器稳定运行了一段时间后运行，根据服务器的”状态”进行优化。
mysql> show global status;
可以列出MySQL服务器运行各种状态值，另外，查询MySQL服务器配置信息语句：
mysql> show variables;
一、慢查询
mysql> show variables like '%slow%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | log_slow_queries | ON | | slow_launch_time | 2 | +------------------+-------+ mysql> show global status like '%slow%'; +---------------------+-------+ | Variable_name | Value | +---------------------+-------+ | Slow_launch_threads | 0 | | Slow_queries | 4148 | +---------------------+-------+
配置中打开了记录慢查询，执行时间超过2秒的即为慢查询，系统显示有4148个慢查询，你可以分析慢查询日志，找出有问题的SQL语句，慢查询时间不宜设置过长，否则意义不大，最好在5秒以内，如果你需要微秒级别的慢查询，可以考虑给MySQL打补丁：http://www.percona.com/docs/wiki/release:start，记得找对应的版本。
打开慢查询日志可能会对系统性能有一点点影响，如果你的MySQL是主－从结构，可以考虑打开其中一台从服务器的慢查询日志，这样既可以监控慢查询，对系统性能影响又小。
二、连接数
经常会遇见”MySQL: ERROR 1040: Too many connections”的情况，一种是访问量确实很高，MySQL服务器抗不住，这个时候就要考虑增加从服务器分散读压力，另外一种情况是MySQL配置文件中max_connections值过小：
mysql> show variables like 'max_connections'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 256 | +-----------------+-------+
这台MySQL服务器最大连接数是256，然后查询一下服务器响应的最大连接数：
mysql> show global status like 'Max_used_connections'; +----------------------+-------+ | Variable_name | Value | +----------------------+-------+ | Max_used_connections | 245 | +----------------------+-------+
MySQL服务器过去的最大连接数是245，没有达到服务器连接数上限256，应该没有出现1040错误，比较理想的设置是：
Max_used_connections / max_connections * 100% ≈ 85%
最大连接数占上限连接数的85％左右，如果发现比例在10%以下，MySQL服务器连接数上限设置的过高了。
三、Key_buffer_size
key_buffer_size是对MyISAM表性能影响最大的一个参数，下面一台以MyISAM为主要存储引擎服务器的配置：
mysql> show variables like 'key_buffer_size'; +-----------------+------------+ | Variable_name | Value | +-----------------+------------+ | key_buffer_size | 536870912 | +-----------------+------------+
分配了512MB内存给key_buffer_size，我们再看一下key_buffer_size的使用情况：
mysql> show global status like 'key_read%'; +------------------------+-------------+ | Variable_name | Value | +------------------------+-------------+ | Key_read_requests | 27813678764 | | Key_reads | 6798830 | +------------------------+-------------+
一共有27813678764个索引读取请求，有6798830个请求在内存中没有找到直接从硬盘读取索引，计算索引未命中缓存的概率：
key_cache_miss_rate ＝ Key_reads / Key_read_requests * 100%
比如上面的数据，key_cache_miss_rate为0.0244%，4000个索引读取请求才有一个直接读硬盘，已经很BT了，key_cache_miss_rate在0.1%以下都很好（每1000个请求有一个直接读硬盘），如果key_cache_miss_rate在0.01%以下的话，key_buffer_size分配的过多，可以适当减少。
MySQL服务器还提供了key_blocks_*参数：
mysql> show global status like 'key_blocks_u%'; +------------------------+-------------+ | Variable_name | Value | +------------------------+-------------+ | Key_blocks_unused | 0 | | Key_blocks_used | 413543 | +------------------------+-------------+
Key_blocks_unused表示未使用的缓存簇(blocks)数，Key_blocks_used表示曾经用到的最大的blocks数，比如这台服务器，所有的缓存都用到了，要么增加key_buffer_size，要么就是过渡索引了，把缓存占满了。比较理想的设置：
Key_blocks_used / (Key_blocks_unused + Key_blocks_used) * 100% ≈ 80%
四、临时表
mysql> show global status like 'created_tmp%'; +-------------------------+---------+ | Variable_name | Value | +-------------------------+---------+ | Created_tmp_disk_tables | 21197 | | Created_tmp_files | 58 | | Created_tmp_tables | 1771587 | +-------------------------+---------+
每次创建临时表，Created_tmp_tables增加，如果是在磁盘上创建临时表，Created_tmp_disk_tables也增加,Created_tmp_files表示MySQL服务创建的临时文件文件数，比较理想的配置是：
Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25%
比如上面的服务器Created_tmp_disk_tables / Created_tmp_tables * 100% ＝ 1.20%，应该相当好了。我们再看一下MySQL服务器对临时表的配置：
mysql> show variables where Variable_name in ('tmp_table_size', 'max_heap_table_size');
+---------------------+-----------+
| Variable_name | Value |
+---------------------+-----------+
| max_heap_table_size | 268435456 |
| tmp_table_size | 536870912 |
+---------------------+-----------+
只有256MB以下的临时表才能全部放内存，超过的就会用到硬盘临时表。
五、Open Table情况
mysql> show global status like 'open%tables%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Open_tables | 919 | | Opened_tables | 1951 | +---------------+-------+
Open_tables表示打开表的数量，Opened_tables表示打开过的表数量，如果Opened_tables数量过大，说明配置中table_cache(5.1.3之后这个值叫做table_open_cache)值可能太小，我们查询一下服务器table_cache值：
mysql> show variables like 'table_cache'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | table_cache | 2048 | +---------------+-------+
比较合适的值为：
Open_tables / Opened_tables * 100% >= 85%
Open_tables / table_cache * 100% <= 95%
待续，本文参考以下网页：
1.http://dev.mysql.com/doc/refman/5.1/en/server-status-variables.htm
2.http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html
3.http://www.ibm.com/developerworks/cn/linux/l-tune-lamp-3.html
4.http://www.day32.com/MySQL/tuning-primer.sh 具体数值主要参考此工具
上周在内部和大家分享了一下jQuery的选择器，做了一个简单的demo：http://chaoqun.17348.com/static/jQuery-selector-demo.html，直接调用的google js api，可以直接下载到本地运行，列出了一些常用的选择器方法，最后一个是动态选择器，可以传入一个变量来选择。文档就不写了，参阅：http://docs.jquery.com/Main_Page，直接看Demo演示吧。
以前看过很多文章说MySQL一次查询只能用到一个索引，在实践中也没注意，一直奉为金科玉律，以此教育自己不要乱建索引，殊不知已是明日黄花。
MySQL5.0以后引入了index_merge，在一些特定的查询中可以合并索引，详细的内容查看[中文] [英文]，接着测试一下，还是那张表，数据还是10,000条。
mysql> desc tbl_name; +-------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+--------------+------+-----+---------+-------+ | uid | int(11) | NO | MUL | NULL | | | sid | mediumint(9) | NO | | NULL | | | times | mediumint(9) | NO | | NULL | | +-------+--------------+------+-----+---------+-------+ 3 rows in set (0.00 sec)
执行查询测试：
mysql> explain select * from tbl_name where uid = 104460 and times = 38\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tbl_name
type: ref
possible_keys: uid
key: uid
key_len: 4
ref: const
rows: 9
Extra: Using where
1 row in set (0.00 sec)
用到了uid索引，扫描了9行。在times上也加上索引：
mysql> create index times on tbl_name(times);
再执行上面的查询：
mysql> explain select * from tbl_name where uid = 104460 and times = 38\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tbl_name
type: index_merge
possible_keys: uid,times
key: uid,times
key_len: 4,3
ref: NULL
rows: 1
Extra: Using intersect(uid,times); Using where
1 row in set (0.00 sec)
用到了索引合并交集访问算法，只扫描了一行。注意索引合并只对一些特定的查询有用（注意看文档），比如下面的：
mysql> explain select * from tbl_name where uid = 104460 and times > 38\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tbl_name
type: ref
possible_keys: uid,times
key: uid
key_len: 4
ref: const
rows: 9
Extra: Using where
1 row in set (0.00 sec)
挂了，还是只用到了uid索引，貌似还和MySQL的版本有一些关系，可以看看这篇博文http://www.alidba.net/index.php/archives/81
致歉，我传讹了，请大家更新”大脑数据库”，感谢xiaowei同学提醒，不知道的还很多，共同学习，一起进步。
Tags: index_merge, MySQL