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 …能看到此参数）的角度看是否合适的问题，这些细节问题需要读者自己多注意，我就不多说了。
相关文档：
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语� ......
1. -static 13%
--with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static
静态链接提高13%性能
2. -pgcc 1%
CFLAGS="-O3 -mpentiumpro -mstack-align-double" CXX=gcc \
CXXFLAGS="-O3 -mpentiumpro -mstack-alig ......
在使用JDBC操作数据库 在向数据库中插入图片时，程序老是抛异常
原来的MYSQL字符集是GBK 但是这种字符集虽然支持中文 但是当插入图片等二进制数据时 会出现错误
解决方法：
将数据库字符集更改为gb2312或utf-8
1.在MYSQL DOS界面中输入 show variables like "%char%";
+---- ......
本文主要介绍mysql数据库下show命令的主要用法：
a. show tables或show tables from database_name; -- 显示当前数据库中所有表的名称。
b. show databases; -- 显示mysql中所有数据库的名称。
c. show columns from table_name from database_name; 或show columns from database_name.table_n ......
