Mysql进阶第五天

索引与执行计划

索引入门

索引是什么？

生活中的索引

MySQL 官方对索引的定义为：索引（Index）是帮助 MySQL 高效获取数据的数据结构。可以得到索引的本质：索引是数据结构。

上面的理解比较抽象，举一个例子，平时看任何一本书，首先看到的都是目录，通过目录去查询书籍里面的内容会非常的迅速。

上图就是一本金瓶梅的书，书籍的目录是按顺序放置的，有第一节，第二节它本身就是一种顺序存放的数据结构，是一种顺序结构。

另外通过目录（索引），可以快速查询到目录里面的内容，它能高效获取数据，通过这个简单的案例可以理解索引就是高效获取数据的数据结构,再来看一个复杂的情况:

我们要去图书馆找一本书，这图书馆的书肯定不是线性存放的，它对不同的书籍内容进行了分类存放，整索引由于一个个节点组成，根节点有中间节点，中间节点下面又由子节点，最后一层是叶子节点；

可见，整个索引结构是一棵倒挂着的树，其实它就是一种数据结构，这种数据结构比前面讲到的线性目录更好的增加了查询的速度。

MySql 中的索引

MySql 中的索引其实也是这么一回事，我们可以在数据库中建立一系列的索引，比如创建主键的时候默认会创建主键索引，上图是一种 BTREE 的索引。每一个节点都是主键的 ID，当我们通过 ID 来查询内容的时候，首先去查索引库，在到索引库后能快速的定位索引的具体位置。

谈下 B+Tree

要谈 B+TREE 说白了还是 Tree,但谈这些之前还要从基础开始讲起。

二分查找

二分查找法（binary search） 也称为折半查找法，用来查找一组有序的记录数组中的某一记录。

其基本思想是：将记录按有序化（递增或递减）排列，在查找过程中采用跳跃式方式查找，即先以有序数列的中点位置作为比较对象，如果要找的元素值小于该中点元素，则将待查序列缩小为左半部分，否则为右半部分。通过一次比较，将查找区间缩小一半。

# 给出一个例子，注意该例子已经是升序排序的，且查找 数字 48

数据：5， 10， 19， 21， 31， 37， 42， 48， 50， 52

下标：0， 1， 2， 3， 4， 5， 6， 7， 8， 9

• 步骤一：设 low 为下标最小值 0 ， high 为下标最大值 9 ; 

• 步骤二：通过 low 和 high 得到 mid ，mid=（low + high） / 2，初始时 mid 为下标 4 (也可以=5，看具体算法实现)；

• 步骤三 ： mid=4 对应的数据值是 31，31 < 48（我们要找的数字）；

• 步骤四：通过二分查找的思路，将 low 设置为 31 对应的下标 4 ， high 保持不变为 9 ，此时 mid 为 6 ；

• 步骤五 ： mid=6 对应的数据值是 42，42 < 48（我们要找的数字）；

• 步骤六：通过二分查找的思路，将 low 设置为 42 对应的下标 6 ， high 保持不变为 9 ，此时 mid 为 7 ；

• 步骤七 ： mid=7 对应的数据值是 48，48 == 48（我们要找的数字），查找结束；

通过 3 次 二分查找 就找到了我们所要的数字，而顺序查找需 8 。

二叉树(Binary Tree)

每个节点至多只有二棵子树；

• 二叉树的子树有左右之分，次序不能颠倒；

• 一棵深度为 k，且有 (2的k次幂减1) 个节点，称为满二叉树(Full Tree)；

• 一棵深度为 k，且 root 到 k-1 层的节点树都达到最大，第 k 层的所有节点都 连续集中在最左边，此时为完全二叉树（Complete Tree）。

平衡二叉树（AVL-树）

 左子树和右子树都是平衡二叉树；

 左子树和右子树的高度差绝对值不超过 1。

平衡二叉树：

非平衡二叉树：

平衡二叉树的遍历

 前序 ：6 ,3, 2, 5,7, 8（ROOT 节点在开头, 中 -左-右 顺序）

 中序 ：2, 3, 5, 6,7, 8（中序遍历即为升序，左- 中 -右 顺序）

 后序 ：2, 5, 3, 8,7, 6 （ROOT 节点在结尾，左-右- 中 顺序）

平衡二叉树的旋转

需要通过旋转（左旋，右旋）来维护平衡二叉树的平衡，在添加和删除的时候需要有额外的开销。

B+Tree

B+树的定义

 数据只存储在叶子节点上，非叶子节点只保存索引信息；

◦ 非叶子节点（索引节点）存储的只是一个 Flag，不保存实际数据记录；

◦ 索引节点指示该节点的左子树比这个 Flag 小，而右子树大于等于这个 Flag 。

 叶子节点本身按照数据的升序排序进行链接(串联起来)；

◦ 叶子节点中的数据在 物理存储上是无序 的，仅仅是在 逻辑上有序 （通过指针串在一起）。

B+树的作用

 在块设备上，通过 B+树可以有效的存储数据；

 所有记录都存储在叶子节点上，非叶子(non-leaf)存储索引(keys)信息；

 B+树含有非常高的扇出（fanout），通常超过 100，在查找一个记录时，可以有效的减少 IO 操作。

B+树的扇出(fan out)

 该 B+ 树高度为 2

 每叶子页（LeafPage）4 条记录

 扇出数为 5

 叶子节点(LeafPage)由小到大（有序）串联在一起

扇出： 是每个索引节点(Non-LeafPage)指向每个叶子节点(LeafPage)的指针；

扇出数 = 索引节点(Non-LeafPage)可存储的最大关键字个数 + 1；

图例中的索引节点(Non-LeafPage)最大可以存放 4 个关键字，但实际使用了 3 个。

B+树的插入操作

• B+树的插入：B+树的插入必须保证插入后叶子节点中的记录依然排序。

问题：1 插入 28

问题 2：插入 70

问题 3：插入 95

要想更好的了解插入规则，这个链接里面写得很详细：https://blog.csdn.net/shenchaohao12321/article/details/83243314 

索引的分类

普通索引：即一个索引只包含单个列，一个表可以有多个单列索引

唯一索引：索引列的值必须唯一，但允许有空值

复合索引：即一个索引包含多个列

聚簇索引(聚集索引)：并不是一种单独的索引类型，而是一种数据存储方式。具体细节取决于不同的实现，InnoDB 的聚簇索引其实就是在同一个结构中保存了 B-Tree 索引(技术上来说是 B+Tree)和数据行。

非聚簇索引：不是聚簇索引，就是非聚簇索引

基础语法

查看索引

SHOW INDEX FROM table_name\G

创建索引

CREATE [UNIQUE ] INDEX indexName ON mytable(columnname(length));

ALTER TABLE 表名 ADD [UNIQUE ] INDEX [indexName] ON (columnname(length));

删除索引

DROP INDEX [indexName] ON mytable;

执行计划

什么是执行计划?

使用 EXPLAIN 关键字可以模拟优化器执行 SQL 查询语句，从而知道 MySQL 是如何处理你的 SQL 语句的。分析你的查询语句或是表结构的性能瓶颈

 执行计划的作用

 表的读取顺序

 数据读取操作的操作类型

 哪些索引可以使用

 哪些索引被实际使用

 表之间的引用

 每张表有多少行被优化器查询

以上的这些作用会在执行计划详解里面介绍到，在这里不做解释。

执行计划的语法

执行计划的语法其实非常简单： 在 SQL 查询的前面加上 EXPLAIN 关键字就行。

比如：EXPLAIN select * from table1 ;

重点的就是 EXPLAIN 后面你要分析的 SQL 语句 。

执行计划详解

通过 EXPLAIN 关键分析的结果由以下列组成，接下来挨个分析每一个列：

ID 列

ID 列：描述 select 查询的序列号,包含一组数字，表示查询中执行 select 子句或操作表的顺序；

根据 ID 的数值结果可以分成一下三种情况：

 id 相同：执行顺序由上至下

 id 不同：如果是子查询，id 的序号会递增，id 值越大优先级越高，越先被执行

 id 相同又不同：同时存在

分别举例来看：

ID 相同：

如上图所示，ID 列的值全为 1，代表执行的允许从 t1 开始加载，依次为 t3 与 t2

EXPLAIN

select t2.* from t1,t2,t3 where t1.id = t2.id and t1.id = t3.id

and t1.other_column = ' ';

ID 不同：

如果是子查询，id 的序号会递增，id 值越大优先级越高，越先被执行；

EXPLAIN

select t2.* from t2 where id = (

select id from t1 where id = (select t3.id from t3 where t3.other_column=' ‘’));

ID 相同又不同：

id 如果相同，可以认为是一组，从上往下顺序执行；

在所有组中，id 值越大，优先级越高，越先执行；

EXPLAIN

select t2.* from (

select t3.id

from t3 where t3.other_column = '' ) s1 ,t2 where s1.id = t2.id ；

select_type 列

Select_type: 查询的类型，使用类型的区别:普通查询、联合查询、子查询等的复杂查询；

类型如下：

SIMPLE

EXPLAIN select * from t1；

简单的 select 查询,查询中不包含子查询或者 UNION；

PRIMARY 与 SUBQUERY

PRIMARY：查询中若包含任何复杂的子部分，最外层查询则被标记为

SUBQUERY：在 SELECT 或 WHERE 列表中包含了子查询

EXPLAIN

select t1.*,(select t2.id from t2 where t2.id = 1 ) from t1；

DERIVED

在 FROM 列表中包含的子查询被标记为 DERIVED(衍生)；

MySQL 会递归执行这些子查询, 把结果放在临时表里。

select t1.* from t1 ,(select t2.* from t2 where t2.id = 1 ) s2 where t1.id = s2.id ；

UNION RESULT 与 UNION

UNION：若第二个 SELECT 出现在 UNION 之后，则被标记为 UNION；

UNION RESULT：从 UNION 表获取结果的 SELECT 。

#UNION RESULT ,UNION

EXPLAIN

select * from t2

UNION

select * from t2 ；

table 列

显示这一行的数据是关于哪张表的：

Type 列

type 显示的是访问类型，是较为重要的一个指标，结果值从最好到最坏依次是：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery >index_subquery > range > index > ALL 。

需要记忆的：

system>const>eq_ref>ref>range>index>ALL ；

一般来说，得保证查询至少达到 range 级别，最好能达到 ref。

System 与 const

System：表只有一行记录（等于系统表），这是 const 类型的特列，平时不会出现，这个也可以忽略不计；

Const：表示通过索引一次就找到了；

const 用于比较 primary key 或者 unique 索引。因为只匹配一行数据，所以很快；

如将主键置于 where 列表中，MySQL 就能将该查询转换为一个常量 。

EXPLAIN

SELECT * from (select * from t2 where id = 1) d1;

eq_ref

唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描；

EXPLAIN

SELECT * from t1,t2 where t1.id = t2.id ；

Ref

非唯一性索引扫描，返回匹配某个单独值的所有行. 本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而，它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体。

EXPLAIN

select count(DISTINCT col1) from t1 where col1 = 'ac' ；

或者

EXPLAIN

select col1 from t1 where col1 = 'ac' ；

Range

只检索给定范围的行,使用一个索引来选择行。key 列显示使用了哪个索引，一般就是在你的 where 语句中出现了 between、<、>、in 等的查询。

这种范围扫描索引扫描比全表扫描要好，因为它只需要开始于索引的某一点，而结束语另一点，不用扫描全部索引。

EXPLAIN select * from t1 where id BETWEEN 30 and 60 ；

EXPLAIN select * from t1 where id in(1,2) ；

Index

当查询的结果全为索引列的时候，虽然也是全部扫描，但是只查询的索引库，而没有去查询数据。

EXPLAIN

select c2 from testdemo ；

All

Full Table Scan，将遍历全表以找到匹配的行。

possible_keys 与 Key

possible_keys:可能使用的 key ；

Key:实际使用的索引。如果为 NULL，则没有使用索引 ；

查询中若使用了覆盖索引，则该索引和查询的 select 字段重叠 ；

这里的覆盖索引非常重要，后面会单独的来讲 。

EXPLAIN select col1,col2 from t1 ；

其中 key 和 possible_keys 都可以出现 null 的情况 。

key_len

EXPLAIN

select * from ta where col1 ='ab';

EXPLAIN

select * from ta where col1 ='ab' and col2 = 'ac' Key_len ；

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。在不损失精确性的情况下，长度越短越好。

key_len 显示的值为索引字段的最大可能长度，并非实际使用长度，即 key_len 是根据表定义计算而得，不是通过表内检索出的。

 key_len 表示索引使用的字节数；

 根据这个值，就可以判断索引使用情况，特别是在组合索引的时候，判断所有的索引字段是否都被查询用到；

 char 和 varchar 跟字符编码也有密切的联系；

 latin1 占用 1 个字节，gbk 占用 2 个字节，utf8 占用 3 个字节。（不同字符编码占用的存储空间不同）。

字符类型

以上这个表列出了所有字符类型，但真正建所有的类型常用情况只是 CHAR、VARCHAR 。

字符类型-索引字段为 char 类型+不可为 Null 时

CREATE TABLE `s1` (

`id` int(11) NOT NULL AUTO_INCREMENT, `name` char(10) NOT NULL, `addr` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`), KEY `name` (`name`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 ;

explain select * from s1 where name='enjoy';

name 这一列为 char(10),字符集为 utf-8 占用 3 个字节；

Keylen=10*3 。

字符类型-索引字段为 char 类型+允许为 Null 时

CREATE TABLE `s2` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`name` char(10) DEFAULT NULL, `addr` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`), KEY `name` (`name`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

explain select * from s2 where name='enjoyedu';

name 这一列为 char(10),字符集为 utf-8 占用 3 个字节,外加需要存入一个 null 值；

Keylen=10*3+1(null) 结果为 31 。

索引字段为 varchar 类型+不可为 Null 时

CREATE TABLE `s3` (

`id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(10) NOT NULL, `addr` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`), KEY `name` (`name`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

explain select * from s3 where name='enjoyeud';

Keylen=varchar(n)变长字段+不允许 Null=n*(utf8=3,gbk=2,latin1=1)+2 。

索引字段为 varchar 类型+允许为 Null 时

CREATE TABLE `s3` (

`id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(10) NOT NULL, `addr` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`), KEY `name` (`name`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

explain select * from s3 where name='enjoyeud';

Keylen=varchar(n)变长字段+允许 Null=n*(utf8=3,gbk=2,latin1=1)+1(NULL)+2 。

数值类型

CREATE TABLE `numberKeyLen ` (

`c0` int(255) NOT NULL , 

`c1` tinyint(255) NULL DEFAULT NULL , 

`c2` smallint(255) NULL DEFAULT NULL , 

`c3` mediumint(255) NULL DEFAULT NULL ,

 `c4` int(255) NULL DEFAULT NULL , 

`c5` bigint(255) NULL DEFAULT NULL , 

`c6` float(255,0) NULL DEFAULT NULL , 

`c7` double(255,0) NULL DEFAULT NULL , 

PRIMARY KEY (`c0`), 

INDEX `index_tinyint` (`c1`) USING BTREE , 

INDEX `index_smallint` (`c2`) USING BTREE , 

INDEX `index_mediumint` (`c3`) USING BTREE , 

INDEX `index_int` (`c4`) USING BTREE , 

INDEX `index_bigint` (`c5`) USING BTREE , 

INDEX `index_float` (`c6`) USING BTREE , 

INDEX `index_double` (`c7`) USING BTREE

)ENGINE=Innodb 

DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci

ROW_FORMAT=COMPACT;

EXPLAIN

select * from numberKeyLen where c1=1

EXPLAIN

select * from numberKeyLen where c2=1

EXPLAIN

select * from numberKeyLen where c3=1

EXPLAIN

select * from numberKeyLen where c4=1

EXPLAIN

select * from numberKeyLen where c5=1

EXPLAIN

select * from numberKeyLen where c6=1

EXPLAIN

select * from numberKeyLen where c7=1

日期和时间

datetime 类型在 5.6 中字段长度是 5 个字节；

datetime 类型在 5.5 中字段长度是 8 个字节；

CREATE TABLE `datatimekeylen ` (

`c1` date NULL DEFAULT NULL , 

`c2` time NULL DEFAULT NULL , 

`c3` year NULL DEFAULT NULL , 

`c4` datetime NULL DEFAULT NULL , 

`c5` timestamp NULL DEFAULT NULL , 

INDEX `index_date` (`c1`) USING BTREE , 

INDEX `index_time` (`c2`) USING BTREE , 

INDEX `index_year` (`c3`) USING BTREE , 

INDEX `index_datetime` (`c4`) USING BTREE , 

INDEX `index_timestamp` (`c5`) USING BTREE

)ENGINE=Innodb

DEFAULT CHARACTER SET=utf8 COLLATE=utf8_general_ci

ROW_FORMAT=COMPACT;

EXPLAIN

SELECT * from datatimekeylen where c1 = 1

EXPLAIN

SELECT * from datatimekeylen where c2 = 1

EXPLAIN

SELECT * from datatimekeylen where c3 = 1

EXPLAIN

SELECT * from datatimekeylen where c4 = 1

EXPLAIN

SELECT * from datatimekeylen where c5 = 1

总结

字符类型

变长字段需要额外的 2 个字节（VARCHAR 值保存时只保存需要的字符数，另加一个字节来记录长度(如果列声明的长度超过 255，则使用两个字节)，所以 VARCAHR 索引长度计算时候要加 2），固定长度字段不需要额外的字节。

而 NULL 都需要 1 个字节的额外空间,所以索引字段最好不要为 NULL，因为 NULL 让统计更加复杂并且需要额外的存储空间。

复合索引有最左前缀的特性，如果复合索引能全部使用上，则是复合索引字段的索引长度之和，这也可以用来判定复合索引是否部分使用，还是全部使用。

整数/浮点数/时间类型的索引长度

NOT NULL=字段本身的字段长度 ；

NULL=字段本身的字段长度+1(因为需要有是否为空的标记，这个标记需要占用 1个字节) ；

datetime 类型在 5.6 中字段长度是 5 个字节，datetime 类型在 5.5 中字段长度是 8 个字节 。

Ref

显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值 。

EXPLAIN

select * from s1 ,s2 where s1.id = s2.id and s1.name = 'enjoy' ；

由 key_len 可知 t1 表的 idx_col1_col2 被充分使用，col1 匹配 t2 表的 col1，col2 匹配了一个常量，即 'ac' 其中【shared.t2.col1】 为 【数据库.表.列】。

Rows

根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数。

Extra

包含不适合在其他列中显示但十分重要的额外信息。

Using filesort

说明 mysql 会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。

MySQL 中无法利用索引完成的排序操作称为“文件排序”，当发现有 Using filesort 后，实际上就是发现了可以优化的地方。

上图其实是一种索引失效的情况，后面会讲，可以看出查询中用到了个联合索引，索引分别为 col1,col2,col3；

当我排序新增了个 col2，发现 using filesort 就没有了。

EXPLAIN select col1 from t1 where col1='ac' order by col3 ；

EXPLAIN select col1 from t1 where col1='ac' order by col2,col3 ；

Using temporary

使了用临时表保存中间结果,MySQL 在对查询结果排序时使用临时表。常见于排序 order by和分组查询 group by。

尤其发现在执行计划里面有 using filesort 而且还有 Using temporary 的时候，特别需要注意。

EXPLAIN select col1 from t1 where col1 in('ac','ab','aa') GROUP BY col2 ；

EXPLAIN select col1 from t1 where col1 in('ac','ab','aa') GROUP BY col1,col2；

Using index

表示相应的 select 操作中使用了覆盖索引(Covering Index)，避免访问了表的数据行，效率不错！

如果同时出现 using where，表明索引被用来执行索引键值的查找;

如果没有同时出现 using where，表明索引用来读取数据而非执行查找动作；

EXPLAIN select col2 from t1 where col1 = 'ab' ；

EXPLAIN select col2 from t1；

覆盖索引

覆盖索引（Covering Index）,一说为索引覆盖。

理解方式一：就是 select 的数据列只用从索引中就能够取得，不必读取数据行，MySQL 可以利用索引返回 select 列表中的字段，而不必根据索引再次读取数据文件,换句话说查询列要被所建的索引覆盖。

理解方式二：索引是高效找到行的一个方法，但是一般数据库也能使用索引找到一个列的数据，因此它不必读取整个行。毕竟索引叶子节点存储了它们索引的数据;当能通过读取索引就可以得到想要的数据，那就不需要读取行了。一个索引包含了(或覆盖了)满足查询结果的数据就叫做覆盖索引。

注意：

如果要使用覆盖索引，一定要注意 select 列表中只取出需要的列，不可 select *，因为如果将所有字段一起做索引会导致索引文件过大，查询性能下降。

所以，千万不能为了查询而在所有列上都建立索引，会严重影响修改维护的性能。

Using where 与 using join buffer

Using where：表明使用了 where 过滤 ；

using join buffer：使用了连接缓存：show VARIABLES like '%join_buffer_size%'；

EXPLAIN

select * from t1 JOIN t2 on t1.other_column = t2.other_column；

impossible where

where 子句的值总是 false，不能用来获取任何元组 ；

EXPLAIN

select * from t1 where 1=2；

EXPLAIN

select * from t1 where t1.other_column ='enjoy' and t1.other_column = 'edu' ；

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