【转】加速动态网站之MySQL索引分析和优化
一、什么是索引？
索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。
假设我们创建了一个名为people的表：
CREATE TABLE people ( peopleid SMALLINT NOT NULL,
name CHAR(50) NOT NULL );
然后，我们完全随机把1000个不同name值插入到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 [索引的名字] (列的列表) );
主键
相关文档：
代码如下：
1 String command = " cmd /c C:/Program Files/MySQL/MySQL Server 5.0/bin>mysqldump -h localhost -u root -p aijia > E:/aijia.dmp " ;
2 try {
3 Process process& ......
不同数据库之间的语法差异还真不少~要崩溃了。
1.创建带自增列临时表：create TEMPORARY table t(id int AUTO_INCREMENT PRIMARY key, u_name varchar(50));--为什么必须要主键？！
向这个临时表中插入数据：insert into t values(null, 'zdy');--为什么一定要加null？！
2.把一张表的查询结果插入临时表：insert into t ......
普通MySQL运行，数据量和访问量不大的话，是足够快的，但是当数据量和访问量剧增的时候，那么就会明显发现MySQL很慢，甚至down掉，那么就要考虑优化我们的MySQL了。
优化无非是从三个角度入手：
第一个是从硬件，增加硬件，增加服务器
第二个就是对我们的MySQL服务器进行优化，增加缓存大小，开多端口，读写分开
第三个 ......
在 MySQL下，在进行中文模糊检索时，经常会返回一些与之不相关的记录，如查找 "%a%" 时，返回的可能有中文字符，却没有a字符存在。本人以前也曾遇到过类似问题，经详细阅读MySQL的Manual，发现可以有一种方法很方便的解决并得到满意的结果。
例子：
希望通过“标题”对新闻库进行检索，关键字可能包含� ......
最近网站数据量节节攀升，据BD方面通报短期内UV还要上升30%-50%。当前最突出的问题是后台内容审核系统压力太大，已经逐渐力不从心。尽管加了一些硬件但效果并不是太理想，主要还是前一段时间把工作重点都放在前端模块上了。内容管理平台的部分代码没有仔细斟酌。接下来一段时间集中精力优化后台。
首先将多表连查的SQL拿出 ......
