MySQL里建立索引应该考虑数据库引擎的类型
前一直没注意这一点，突然一闪念想起来，下面唠唠：
比方说有一个文章表，我们要实现某个类别下按时间倒序列表显示功能：
SELECT * from articles WHERE category_id = … ORDER BY created DESC LIMIT …
这样的查询很常见，基本上不管什么应用里都能找出一大把类似的SQL来，学院派的读者看到上面的SQL，可能会说SELECT *不好，应该仅仅查询需要的字段，那我们就索性彻底点，把SQL改成如下的形式：
SELECT id from articles WHERE category_id = … ORDER BY created DESC LIMIT …
我们假设这里的id是主键，至于文章的具体内容，可以都保存到memcached之类的键值类型的缓存里，如此一来，学院派的读者们应该挑不出什么毛病来了，下面我们就按这条SQL来考虑如何建立索引：
不考虑数据分布之类的具体情况，任何一个合格的WEB开发人员都知道类似这样的SQL，应该建立一个”category_id, created“复合索引，但这是最佳答案不？不见得，现在是回头看看标题的时候了：MySQL里建立索引应该考虑数据库引擎的类型！
如果我们的数据库引擎是InnoDB，那么建立”category_id, created“复合索引是最佳答案。让我们看看InnoDB的索引结构，在InnoDB里，索引结构有一个特殊的地方：非主键索引在其BTree的叶节点上会额外保存对应主键的值，这样做一个最直接的好处就是Covering Index，不用再到数据文件里去取id的值，可以直接在索引里得到它。
如果我们的数据库引擎是MyISAM，那么建立”category_id, created”复合索引就不是最佳答案。因为MyISAM的索引结构里，非主键索引并没有额外保存对应主键的值，此时如果想利用上Covering Index，应该建立”category_id, created, id”复合索引。
唠完了，应该明白我的意思了吧。希望以后大家在考虑索引的时候能思考的更全面一点，实际应用中还有很多类似的问题，比如说多数人在建立索引的时候不从Cardinality（SHOW INDEX from …能看到此参数）的角度看是否合适的问题，这些细节问题需要读者自己多注意，我就不多说了。
相关文档：
1. 使用GRANT语句添加：首先在数据库本机上用ROOT用户
登录MySql（我是用远程控制linux服务器，相当于在服务器本机登录MySql了），然后输入：
mysql>GRANT ALL PRIVILEGES ON *.* TO admin@localhost IDENTIFIED BY 'something' WITH GRANT OPTION;
添加一个用户admin并授权通过本地机（localhost)访问，密码“s ......
use mysql
update user set Password=password('newpassword') where User='root';
flush privileges;
1.通过修改MYSQL数据库中MYSQL库的USER表
就用普通的UPDATE、INSERT语句就可以
2.在命令行中使用如下命令
MYSQLADMIN -u root -p PASSWORD mypasswd
3.可以修改MYSQL文件夹中的MY.INI文件
4.使用SET PASSWORD语� ......
MySQL 5.1.40已经发布，在这里有一些新的特性出现，包括MySQL基群基于磁盘的数据支持等等。 MySQL 5.1.40已经发布，这一版本的MySQL有很多新的功能特性，希望这些新特性能让大家今后的工作更有效率。MySQL是现在最流行一个多线程的,结构化查询语言(SQL)数据库服务器.绝大多数PHP网站的数据库后台都是采用这一数据库.
......
这是以读为主的线上库
root@read 02:28:07>show status like ‘Handler_read%’;
+———————–+——-+
| Variable_name | Value |
+————&m ......
针对select * from table where col1 > number order by col2 desc。
其实按照常规的方法可以这样设计：key(col1, col2)
但是这种办法在mysql里不算是理想的，where条件里限定索引前部分是一个范围的情况下后面的order by还是会有filesort。如果where条件里限定索引前部分是一个常量，那么order by就会有效利用索引。� ......
