Day06-SQL基础优化-索引及执行计划

1. 索引的作用

优化查询，类似于书的目录

2. 索引算法分类

Btree
Rtree
Hash
fulltext
gis

3. 聚集索引和辅助索引的逻辑构成

最核心的区别就在叶子节点上，辅助索引是把单列的值存放在叶子节点上，聚集索引是把整行的值存放在叶子节点上。

4. 辅助索引细分

单列
多列（联合索引）
唯一

5. 索引树的高度会受什么影响？

1. 原因：数据行。
解决方法：分表，如果是数据量大，就分区
如果是数据行多，就分表。
2.原因：索索引列值较长。
解决方法：前缀索引。
3. 数据类型（char、varchar、enum）

6. 索引的管理操作

创建索引(普通辅助索引)

alter table t100w add index idx_k2(XYno); 在t100w表中的XYno列上创建一个名为idx_k2的索引。
上述命令会造成短暂的锁表，尽量在在业务不忙的时候做

查看索引：（MUL 普通辅助索引、UNI 唯一索引、PRI 聚集索引）
desc table_name

show index from table_name;
show index from table_name\G

添加唯一索引
特性：列的值不能重复。

查看想设置唯一索引的列是否有重复值

（1）3306 [oldboy]>select count(distinct (k1)) from t100w;
+----------------------+
| count(distinct (k1)) |
+----------------------+
|                 1225 | #1225表示的为不重复的值
+----------------------+
1 row in set (0.48 sec)

（2）3306 [oldboy]> select k1,count(k1) from t100w group by k1 having count(k1)>1;
 #如果显示出来的值（count(k1)）不为1，那就表示它不是唯一的，就不能创建唯一索引。
+------+-----------+
| k1   | count(k1) |
+------+-----------+
| 00   |       266 |
| 01   |       250 |
| 02   |       272 |
……省略部分内容

3306 [oldboy]>alter table t100w add unique index idx_k1(k1);
ERROR 1062 (23000): Duplicate entry 'BX' for key 'idx_k1' #因为K1列有重复值，所以创建唯一索引时报错

添加前缀索引：
注意：前缀索引只能应用到字符串上的列

alter table city add index idx_name(name(5));
#选择name这一列从左到右的前5个字符作为前缀索引

创建联合索引：
联合索引是在多个列上创建的

alter table city add index idex_co_po(countrycode,population);

删除索引：

show index from city;
alter table city drop index idx idex_co_po;

7. 执行计划

7.0 为什么要有执行计划

（1）到底该怎么建立索引
（2）到底怎么去分析用户的行为
（3）如何才能知道索引的设定是否合理
（4）如何知道SQL语句到底走没走索引
以上这些原因，就是要有执行计划的原因，有了执行计划后，就能对执行计划进行分析。
这里的执行计划，正是优化器选择后的执行计划

7.1 作用

上线新的查询语句之前，进行提前预估语句的性能。
在出现性能问题时，找到合理的解决思路。

7.2 执行计划的获取

执行计划的获取,一般是针对select语句进行的

应用场景为：

（1）上线一个新的查询业务之前
（2）出现了性能问题之后

模拟场景：上线一个新的查询业务之前

评估语句为：select * from oldboy.t100w where k2='EF12'

查询方法：

3306 [oldboy]>desc select * from oldboy.t100w where k2='EF12'\G
*************************** 1. row ***************************
           id: 1 （语句的序号，不重要） 
  select_type: SIMPLE  （查询类型：普通的。不用特别关注）
        table: t100w  （表名。重要，表示了执行计划是针对t100w这张表进行的。企业应用场景：多表查询时，可以通过此项来评估，到底是哪张表出了问题）
   partitions: NULL  
         type: ref （重要。索引的类型：）
possible_keys: idx_k2 （重要。可能会使用到的索引：idx_k2）
          key: idx_k2（重要。 实际上使用的索引：idx_k2）
      key_len: 5 （重要。联合索引的覆盖长度。越高越好 ）
          ref: const 
         rows: 573 （重要。查询的行数。这个值越少越好，行数越少，代价越低）
     filtered: 100.00
        Extra: NULL （重要。额外的信息）
1 row in set, 1 warning (0.00 sec)


3306 [oldboy]>explain select * from oldboy.t100w where k2='EF12'\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t100w
   partitions: NULL
         type: ref
possible_keys: idx_k2
          key: idx_k2
      key_len: 5
          ref: const
         rows: 573
     filtered: 100.00
        Extra: NULL
1 row in set, 1 warning (0.01 sec)

7.3 执行计划的分析

type：ref  索引的应用级别

可能的应用级别包括以下几类：

（1）ALL
（2）Index
（3）range
（4）ref
（5）eq_ref
（6）const或system（这两种级别相同）
（7）NULL
上述应用级别是从上到下越来越好。

应用级别详解

ALL：全表扫描，不走索引。（在MySQL的查询中，要么是全表扫描，要么是索引扫描。这种级别在索引优化中应当避免出现）

ALL会出现在两种情况中：
（1）没有索引。
（2）有索引也不走
什么情况下会导致不走索引呢？
（1）没建立索引
（2）建立索后不走索引的。

模拟环境：建立索后不走索引的几种情况

（1）desc select * from t100w; 因为直接查找全表的数据，所以不走索引
（2）desc select * from t100w where k1='aa'; 这里是没有以索引列作为查询条件，所以即使有索引，它也不会走
（3）desc select * from t100w where k2 !='aaaa'; 这里的K2是索引列，但是由于查找的条件排除了k2这一例，所以不走索引
（4）desc select * from t100w where k2 like '%xt%'; 查询语句中应当避免出现双%的情况，因为这种它也是不会走索引的

Index：全索引扫描（扫描整个索引树，这种级别在索引优化中应当避免出现）,查询的值为整个索引列的所有值

出现场景：
（1）desc select k2 from t100w; 这里的K2为辅助索引列

range：索引范围扫描（不扫描整个索引树，而只是扫描一部分索引。在索引优化中出现的级别至少应该是“range”）

出现场景：
辅助索引语句中包含：>、<、>=、<=、like、in、or
in、or（这两种要尽量避免或改写）
主键列：!= 

 模拟场景：
3306 [oldboy]> desc select * from world.city where id>3000;
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | city  | NULL       | range | PRIMARY       | PRIMARY | 4       | NULL | 1079 |   100.00 | Using where |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

3306 [oldboy]>desc select * from world.city where id!=3000;
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | city  | NULL       | range | PRIMARY       | PRIMARY | 4       | NULL | 3173 |   100.00 | Using where |
+----+-------------+-------+------------+-------+---------------+---------+---------+------+------+----------+-------------+
1 row in set, 1 warning (0.10 sec)

3306 [oldboy]>desc select * from world.city where countrycode like 'C%';
+----+-------------+-------+------------+-------+---------------+-------------+---------+------+------+----------+-----------------------+
| id | select_type | table | partitions | type  | possible_keys | key         | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-------+------------+-------+---------------+-------------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | city  | NULL       | range | CountryCode   | CountryCode | 3       | NULL |  551 |   100.00 | Using index condition |
+----+-------------+-------+------------+-------+---------------+-------------+---------+------+------+----------+-----------------------+
1 row in set, 1 warning (0.00 sec)

3306 [oldboy]>desc select * from world.city where countrycode in ('CHN','USA');
+----+-------------+-------+------------+-------+---------------+-------------+---------+------+------+----------+-----------------------+
| id | select_type | table | partitions | type  | possible_keys | key         | key_len | ref  | rows | filtered | Extra                 |
+----+-------------+-------+------------+-------+---------------+-------------+---------+------+------+----------+-----------------------+
|  1 | SIMPLE      | city  | NULL       | range | CountryCode   | CountryCode | 3       | NULL |  637 |   100.00 | Using index condition |
+----+-------------+-------+------------+-------+---------------+-------------+---------+------+------+----------+-----------------------+

改写in的方法：

3306 [oldboy]>desc select * from world.city where countrycode ='CHN' union all select * from world.city where countrycode ='USA';
+----+-------------+-------+------------+------+---------------+-------------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key         | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+-------------+---------+-------+------+----------+-------+
|  1 | PRIMARY     | city  | NULL       | ref  | CountryCode   | CountryCode | 3       | const |  363 |   100.00 | NULL  |
|  2 | UNION       | city  | NULL       | ref  | CountryCode   | CountryCode | 3       | const |  274 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+-------------+---------+-------+------+----------+-------+
2 rows in set, 1 warning (0.00 sec)

ref：辅助索引等值扫描。在同样的数据量级下，ref比range性能要高很多

**出现场景：**

3306 [oldboy]>3306 [oldboy]>desc select * from world.city where countrycode='CHN';
+----+-------------+-------+------------+------+---------------+-------------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key         | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+-------------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | city  | NULL       | ref  | CountryCode   | CountryCode | 3       | const |  363 |   100.00 | NULL  |
+----+-------------+-------+------------+------+---------------+-------------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00 sec)

eq_ref：在多表连接查询时，on的条件列时是唯一索引或主键列。

出现场景：
desc select a.name,b.name,b.surfacearea
from city as a join country as b
on a.countrycode=b.code （on的条件列）
where a.population <100;

const或system（这两种级别相同）：主键或唯一键等值查询，代价（IO）最低。

出现场景：
3306 [oldboy]> desc select * from world.city where id=10;
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type  | possible_keys | key     | key_len | ref   | rows | filtered | Extra |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
|  1 | SIMPLE      | city  | NULL       | const | PRIMARY       | PRIMARY | 4       | const |    1 |   100.00 | NULL  |
+----+-------------+-------+------------+-------+---------------+---------+---------+-------+------+----------+-------+
1 row in set, 1 warning (0.00

NULL：空

出现场景：
几乎不可能，除非要查找的数据不存在。

Extra：：额外的信息
using filesort：当Extra这一栏下出现using filesort时，表示索引设计不合理或语句写错，排序语句最容易出现filesort

注意：

当查询条件出同时出现了where和order by时，必须要加上联合索引，避免出现using filesort

7.4 explain(desc)使用场景（面试题）

题目意思: 我们公司业务慢,请你从数据库的角度分析原因
1.mysql出现性能问题,我总结有两种情况:
（1）应急性的慢：突然夯住，突然卡住，增删改查都无法操作，或反应速度很慢。
处理过程:
1.show processlist(显示用户正在运行的线程); 获取到导致数据库hang的语句

  1. 使用explain或desc 分析SQL的执行计划,有没有走索引,索引的类型情况
  2. 建索引,改语句

（2）一段时间慢(持续性的):

  1. 查看记录慢日志的slowlog,分析slowlog
  2. explain 分析SQL的执行计划,有没有走索引,索引的类型情况
  3. 建索引,改语句

8. 索引应用规范

“业务”，根据业务，建立合理的索引
1.产品的功能
2.用户的行为
"热"查询语句 --->较慢--->slowlog
"热"数据

8.1 建立索引的原则（DBA运维规范）

说明

为了使索引的使用效率更高，在创建索引时，必须考虑在哪些字段上创建索引和创建什么类型的索引。
那么索引设计原则又是怎样的?

（1） (必须的) 建表时一定要有主键,一般是个无关列
（2）选择唯一性索引

唯一性索引的值是唯一的，可以更快速的通过该索引来确定某条记录。
例如，学生表中学号是具有唯一性的字段。为该字段建立唯一性索引可以很快的确定某个学生的信息。
如果使用姓名的话，可能存在同名现象，从而降低查询速度。

重复值查询优化方案:

(1) 如果非得使用重复值较多的列作为查询条件(例如:男女),可以将表逻辑拆分
(2) 可以将此列和其他的查询类,做联和索引
select count(*) from world.city;
select count(distinct countrycode) from world.city;
select count(distinct countrycode,population ) from world.city;

（3）必须要为经常需要where 、ORDER BY、GROUP BY,join on等操作的字段，建立索引。因为排序操作会浪费很多时间。

当一条语句中同时存在where A、GROUP BY B、ORDER BY C怎么办？
1. 联合索引 
2. 必须按照子句的顺序建立联合索引(A,B,C) ，否则会出现漏走索引的情况。
3. 在where后面的条件，如果有group by或order by，尽量where条件不要出现不等值查询。
注：如果经常作为条件的列，重复值特别多，可以建立联合索引。

（4）当查询的字段值很长，可以使用前缀索引来减小索引树的高度

如果索引字段的值很长，最好使用值的前缀来索引。
因为，当查询的字段值很长，数据量级又特别大的情况下，如果直接拿这个列来建立索引，会增加索引树的高度，会增加查询的代价。

（5）限制索引的数目

在MySQL中，一个表最多可以有64个索引，但是索引的数目并不是越多越好。
索引太多可能会产生的问题:
(1) 每个索引都需要占用磁盘空间，索引越多，需要的磁盘空间就越大。
(2) 修改表时，对索引的重构和更新很麻烦。索引太多，会使更新表变得很浪费时间。
(3) 优化器的负担会很重,有可能会影响到优化器的选择.
percona-toolkit中有个工具,专门分析索引是否有用
建立索引建议：
（1）表中条目小于10W行，不用建立索引，可以直接进行全表扫描。
（2）10W行以上，根据业务的特点，合理建立索引。
（3）需要经常更新的列，不建议建立索引。

（6）删除不再使用或者很少使用的索引(percona toolkit)

pt-duplicate-key-checker（检查数据库中重复的索引）
表中的数据被大量更新，或者数据的使用方式被改变后，原有的一些索引可能不再需要。数据库管理
员应当定期找出这些索引，将它们删除，从而减少索引对更新操作的影响。

（7）大表加索引,要在业务不繁忙期间操作
（8）尽量少在经常更新值的列上建索引

总结：建索引原则

(1) 必须要有主键,如果没有可以做为主键条件的列,创建无关列
(2) 经常做为where条件列  order by  group by  join on, distinct 的条件(业务:产品功能+用户行为)
(3) 最好使用唯一值多的列作为索引,如果索引列重复值较多,可以考虑使用联合索引
(4) 列值长度较长的索引列,我们建议使用前缀索引.
(5) 降低索引条目,一方面不要创建没用索引,不常使用的索引要清理掉,percona toolkit(xxxxx)
(6) 索引维护要避开业务繁忙期

关于联合索引

（1）当一条语句中既有where和group by，又有order by时候，一定要建立联合索引，而且查询的值必须是这样(A,B,C)的顺序。
（2）只有where时，怎么办？
1.  假设都是等值 ,在5.5 以后无关索引顺序，把控一个原则：唯一值多的列（重复值少），放在联合索引的最左侧
2. 如果有不等值，例如以下情况
         select where  A= and  B> and  C=xxx 
         建立索引顺序：ACB （等值中，唯一值最多的放在最前面，不等值放在最后面）
                语句改写为 ：ACB（等值中，唯一值最多的放在最前面，不等值放在最后面）

8.2 不走索引的情况有哪些（开发规范）

1. 没有查询条件，或者查询条件没有建立索引

select * from tab;       全表扫描不走索引。
在业务数据库中，特别是数据量比较大的表。
是没有全表扫描这种需求。
1、对用户查看是非常痛苦的。
2、对服务器来讲毁灭性的。
（1）
select * from tab;
SQL改写成以下语句：
select  * from  tab  order by  price  limit 10 ;    需要在price列上建立索引。limit 10 取前10行。
（2）
select  * from  tab where name='zhangsan'          name列没有索引
改：
1、换成有索引的列作为查询条件
2、将name列建立索引

2. 查询结果集是原表中的大部分数据(25％以上)。

当查询的结果集，超过了总数行数25%，优化器会觉得就没有必要走索引了，自动转换为全表扫描。
假如：tab表 id，name    id:1-100w  ，id列有(辅助)索引
select * from tab  where id>500000;
如果业务允许，可以使用limit控制。
怎么改写 ？
结合业务判断，有没有更好的方式。如果没有更好的改写方案，就尽量不要在mysql存放这个数据了。放到redis里面。

3. 索引本身失效，统计数据不真实

索引本身其实是有自我维护能力的 。
对于表内容变化比较频繁的情况下，有可能会出现索引失效。
解决办法一般是删除重建

现象:
有一条select语句平常查询时很快,突然有一天很慢,会是什么原因
select?  --->索引失效,，统计数据不真实
DML ?   --->锁冲突，耗尽了所有资源，导致什么也干不了。
4. 查询条件使用函数在索引列上，或者对索引列进行运算，运算包括(+，-，*，/，! 等)
例子：
错误的例子：select * from test where id-1=9;
正确的例子：select * from test where id=10;
算术运算
函数运算
子查询

5. 隐式转换导致索引失效.这一点应当引起重视.也是开发中经常会犯的错误.

这样会导致索引失效. 
错误例子演示：
mysql> alter table tab add index inx_tel(telnum);
Query OK, 0 rows affected (0.03 sec)
Records: 0  Duplicates: 0  Warnings: 0
mysql>
mysql> desc tab;
+--------+-------------+------+-----+---------+-------+
| Field  | Type        | Null | Key | Default | Extra |
+--------+-------------+------+-----+---------+-------+
| id    | int(11)    | YES  |    | NULL    |      |
| name  | varchar(20) | YES  |    | NULL    |      |
| telnum | varchar(20) | YES  | MUL | NULL    |      |
+--------+-------------+------+-----+---------+-------+

3 rows in set (0.01 sec)
mysql> select * from tab where telnum='1333333';
+------+------+---------+
| id  | name | telnum  |
+------+------+---------+
|    1 | a    | 1333333 |
+------+------+---------+
1 row in set (0.00 sec)
mysql> select * from tab where telnum=1333333;
+------+------+---------+
| id  | name | telnum  |
+------+------+---------+
|    1 | a    | 1333333 |
+------+------+---------+
1 row in set (0.00 sec)
mysql> explain  select * from tab where telnum='1333333';
+----+-------------+-------+------+---------------+---------+---------+-------+------+-----------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref  | rows | Extra                |
+----+-------------+-------+------+---------------+---------+---------+-------+------+-----------------------+

|  1 | SIMPLE      | tab  | ref  | inx_tel      | inx_tel | 63      | const |    1 | Using index condition |
+----+-------------+-------+------+---------------+---------+---------+-------+------+-----------------------+
1 row in set (0.00 sec)
mysql> explain  select * from tab where telnum=1333333;
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra      |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | tab  | ALL  | inx_tel      | NULL | NULL    | NULL |    2 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)
mysql> explain  select * from tab where telnum=1555555;
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra      |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | tab  | ALL  | inx_tel      | NULL | NULL    | NULL |    2 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)
mysql> explain  select * from tab where telnum='1555555';
+----+-------------+-------+------+---------------+---------+---------+-------+------+-----------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref  | rows | Extra                |
+----+-------------+-------+------+---------------+---------+---------+-------+------+-----------------------+
|  1 | SIMPLE      | tab  | ref  | inx_tel      | inx_tel | 63      | const |    1 | Using index condition |
+----+-------------+-------+------+---------------+---------+---------+-------+------+-----------------------+
1 row in set (0.00 sec)
mysql>

总结：上面的telnum定义的为字符串类型，但是where查询的时候，查询的是数字，所以不走索引。加上单引号就走索引了。

6. <> ，not in 出现在辅助索引列的时候，不走索引

EXPLAIN  SELECT * FROM teltab WHERE telnum  <> '110';
EXPLAIN  SELECT * FROM teltab WHERE telnum  NOT IN ('110','119');

mysql> select * from tab where telnum <> '1555555';
+------+------+---------+
| id  | name | telnum  |
+------+------+---------+
|    1 | a    | 1333333 |
+------+------+---------+
1 row in set (0.00 sec)
mysql> explain select * from tab where telnum <> '1555555';

7. 单独的>,<,in 有可能走，也有可能不走，和结果集有关，尽量结合业务添加limit
or或in 尽量改成union all

EXPLAIN  SELECT * FROM teltab WHERE telnum  IN ('110','119');
改写成：
EXPLAIN SELECT * FROM teltab WHERE telnum='110'
UNION ALL
SELECT * FROM teltab WHERE telnum='119'

8. like "%_" 百分号在最前面不走

EXPLAIN SELECT * FROM teltab WHERE telnum LIKE '31%'  走range索引扫描
EXPLAIN SELECT * FROM teltab WHERE telnum LIKE '%110'  不走索引
%linux%类的搜索需求，可以使用elasticsearch或 mongodb 专门做搜索服务的数据库产品

总结：like 专门针对字符串列，数字列不能使用
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 225,226评论 6赞 524
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 96,509评论 3赞 405
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 172,523评论 0赞 370
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 61,181评论 1赞 302
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 70,189评论 6赞 401
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 53,642评论 1赞 316
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 41,993评论 3赞 431
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 40,977评论 0赞 280
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 47,527评论 1赞 326
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 39,547评论 3赞 347
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 41,661评论 1赞 355
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 37,250评论 5赞 351
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 42,991评论 3赞 340
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 33,422评论 0赞 25
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 34,571评论 1赞 277
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 50,241评论 3赞 382
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 46,737评论 2赞 366

推荐阅读更多精彩内容

  • mysql笔记(转)
    今天看到一位朋友写的mysql笔记总结，觉得写的很详细很用心，这里转载一下，供大家参考下，也希望大家能关注他原文地...
    信仰与初衷阅读 4,743评论 0赞 30
  • MySQL--基础优化--及索引执行计划-Day6
    MySQL--基础优化--及索引执行计划-Day6 一、上节回顾： 1、作用 优化查询，类似于书中的目录 2、算法...
    学无止境_9b65阅读 360评论 0赞 0
  • oracle错误集合
    ORA-00001: 违反唯一约束条件 (.) 错误说明：当在唯一索引所对应的列上键入重复值时，会触发此异常。 O...
    我想起个好名字阅读 5,356评论 0赞 9
  • 赠友人
    送君行去，归路无期逢可期。晨起饮朝露，声声慢里迎新日，晕染千层云。 长亭莫留，倚栏无声声有声。秋落拾迟音，...
    愿岁月温柔阅读 170评论 0赞 2
  • 张博睿，恭喜您已步入成年！
    Happy birthday to you. 2019已经是第十年了吧。十年看起来如此久远，却让我觉得曾经的点点滴...
    Fireflies_L阅读 330评论 0赞 0