慢sql的原因

1、针对偶尔很慢的情况下

一、数据库在刷新脏页（需要去了解数据库数据写入的具体过程）

二、拿不到锁

● 这个就比较容易想到了，我们要执行的这条语句，刚好这条语句涉及到的表，别人在用，并且加锁了，我们拿不到锁，只能慢慢等待别人释放锁了。或者，表没有加锁，但要使用到的某个一行被加锁了，这个时候，我也没办法啊。
● 如果要判断是否真的在等待锁，我们可以用 show processlist这个命令来查看当前的状态哦，这里我要提醒一下，有些命令最好记录一下，反正，我被问了好几个命令，都不知道怎么写，呵呵。
查看数据库一些状态的命令：

2、长期一直都这么慢的情况下

表结构：

mysql> CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `c` int(11) DEFAULT NULL,
  `d` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

1、没用到索引

select * from t where 100 <c and c < 100000;

该种情况下，系统可能会走全表扫描（具体情况要看系统的预测，预测也可能出错）

为什么会这样呢？

其实是这样的，系统在执行这条语句的时候，会进行预测：究竟是走 c 索引扫描的行数少，
还是直接扫描全表扫描的行数少呢？显然，扫描行数越少当然越好了，因为扫描行数越少，
意味着I/O操作的次数越少。

如果是扫描全表的话，那么扫描的次数就是这个表的总行数了，假设为 n；而如果走索引 c 的话，
我们通过索引 c 找到主键之后，还得再通过主键索引来找我们整行的数据，也就是说，需要走两次索引。

而且，我们也不知道符合 100 c < and c < 10000 这个条件的数据有多少行，
万一这个表是全部数据都符合呢？这个时候意味着，走 c 索引不仅扫描的行数是 n，
同时还得每行数据走两次索引。

2、字段没有索引

如果数据库表量很大，如果你要经常查询的字段上面没有索引，那么抱歉，只能走全表扫描，会导致查询语句很慢

3、字段索引，但是没有用到

select * from t where c - 1 = 1000;  //  错误做法

select * from t where c = 1000 + 1;		//正确做法

4、函数操作导致没有用上索引

强制走索引

select * from t force index(a) where c < 100 and c < 100000;

查询索引基数和实际是否符合要求，

show index from t;

analyze table t; 重新统计分析 预测基数