MySQL實(shí)踐之排序分析

一著蟹、前言

本文描述了團(tuán)隊(duì)在工作中遇到的一個(gè)MySQL分頁(yè)查詢問(wèn)題煞肾，順帶講解相關(guān)知識(shí)點(diǎn)命贴，為后來(lái)者鑒道宅。本文重點(diǎn)不是"怎樣"優(yōu)化表結(jié)構(gòu)和SQL語(yǔ)句，而是探索不同查詢方式"為什么"會(huì)有顯著差異胸蛛，涉及下列知識(shí)點(diǎn)：

MySQL 延遲關(guān)聯(lián)
MySQL Optimizer Trace使用
MySQL 排序原理

二污茵、問(wèn)題

工作中用到了一張表，字段比較多葬项，每行大概500字節(jié)泞当，總行數(shù)大概80萬(wàn)。場(chǎng)景中民珍，需要根據(jù)某個(gè)非索引字段排序襟士，然后進(jìn)行分頁(yè)讀取。現(xiàn)把脫敏之后的表結(jié)構(gòu)奉上（只修改了字段名）穷缤，通過(guò)簡(jiǎn)單腳本插入80萬(wàn)行模擬數(shù)據(jù)即可以測(cè)試了敌蜂。

2.1 表結(jié)構(gòu)

CREATE TABLE `t` (
 `a0` varchar(16) NOT NULL,
 `a1` bigint(20) NOT NULL,
 `a2` decimal(27,9) NOT NULL DEFAULT '0', `a3` decimal(27,9) NOT NULL DEFAULT '0',
 `a4` decimal(27,9) NOT NULL DEFAULT '0', `a5` decimal(27,9) NOT NULL DEFAULT '0',
 `a6` decimal(27,9) NOT NULL DEFAULT '0', `a7` decimal(27,9) NOT NULL DEFAULT '0',
 `a8` decimal(18,9) NOT NULL DEFAULT '0', `a9` decimal(18,9) NOT NULL DEFAULT '0',
 `b1` decimal(27,9) NOT NULL DEFAULT '0', `b2` decimal(27,9) NOT NULL DEFAULT '0',
 `b3` decimal(18,9) NOT NULL DEFAULT '0', `b4` decimal(18,9) NOT NULL DEFAULT '0',
 `b5` decimal(18,9) NOT NULL DEFAULT '0', `b6` decimal(18,9) NOT NULL DEFAULT '0',
 `b7` decimal(18,9) NOT NULL DEFAULT '0', `b8` decimal(18,9) NOT NULL DEFAULT '0',
 `b9` decimal(18,9) NOT NULL DEFAULT '0', `c1` decimal(18,9) NOT NULL DEFAULT '0',
 `c2` decimal(18,9) NOT NULL DEFAULT '0', `c3` decimal(18,9) NOT NULL DEFAULT '0',
 `c4` decimal(18,9) NOT NULL DEFAULT '0', `c5` decimal(18,9) NOT NULL DEFAULT '0',
 `c6` decimal(18,9) NOT NULL DEFAULT '0', `c7` int(11) NOT NULL DEFAULT '0',
 `c8` int(11) NOT NULL DEFAULT '0', `c9` int(11) NOT NULL DEFAULT '0',
 `d1` int(11) NOT NULL DEFAULT '0', `d2` int(11) NOT NULL DEFAULT '0',
 `d3` decimal(18,9) NOT NULL DEFAULT '0', `d4` decimal(18,9) NOT NULL DEFAULT '0',
 `d5` decimal(18,9) NOT NULL DEFAULT '0', `d6` decimal(18,9) NOT NULL DEFAULT '0',
 `d7` decimal(18,9) NOT NULL DEFAULT '0', `d8` decimal(18,9) NOT NULL DEFAULT '0',
 `d9` int(11) NOT NULL DEFAULT '0', `e1` decimal(27,9) NOT NULL DEFAULT '0',
 `e2` decimal(27,9) NOT NULL DEFAULT '0', `e3` decimal(27,9) NOT NULL DEFAULT '0',
 `e4` decimal(18,9) NOT NULL DEFAULT '0', `e5` decimal(18,9) NOT NULL DEFAULT '0',
 `e6` decimal(18,9) NOT NULL DEFAULT '0', `e7` decimal(18,9) NOT NULL DEFAULT '0',
 `e8` decimal(18,9) NOT NULL DEFAULT '0', `e9` decimal(18,9) NOT NULL DEFAULT '0',
 `f1` decimal(18,9) NOT NULL DEFAULT '0', `f2` decimal(18,9) NOT NULL DEFAULT '0',
 PRIMARY KEY (`a0`,`a1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

查詢顯式用到的字段是a0和a1。再看一下表信息：

#  select * from information_schema.tables where table_name='t'\G
SELECT * FROM tables where table_name='t'\G
*************************** 1. row ***************************
  TABLE_CATALOG: def
   TABLE_SCHEMA: test
     TABLE_NAME: t
     TABLE_TYPE: BASE TABLE
         ENGINE: InnoDB
        VERSION: 10
     ROW_FORMAT: Compact
     TABLE_ROWS: 799304
 AVG_ROW_LENGTH: 482
    DATA_LENGTH: 385875968
MAX_DATA_LENGTH: 0
   INDEX_LENGTH: 0
      DATA_FREE: 5242880
 AUTO_INCREMENT: NULL
    CREATE_TIME: 2017-01-13 09:34:59
    UPDATE_TIME: NULL
     CHECK_TIME: NULL
TABLE_COLLATION: utf8_general_ci
       CHECKSUM: NULL
 CREATE_OPTIONS:
  TABLE_COMMENT:

2.2 兩種查詢

最初津肛，使用最直接的查詢語(yǔ)句章喉，耗時(shí)6.67秒：

SQL_1:   SELECT * FROM t ORDER BY a1 DESC LIMIT 100000,1;

隨后，使用"延遲關(guān)聯(lián)"身坐，耗時(shí)0.90秒：

SQL_2:   SELECT * FROM t INNER JOIN (SELECT a0, a1 FROM t ORDER BY a1 DESC LIMIT 100000,1) AS A USING (a0, a1);

延遲關(guān)聯(lián)秸脱，先根據(jù)條件查詢需要的主鍵，再根據(jù)主鍵關(guān)聯(lián)原表獲得需要的數(shù)據(jù)部蛇。

問(wèn)題：為什么SQL_2比SQL_1執(zhí)行快那么多摊唇？

三、背景知識(shí)

工欲善其事涯鲁，必先利其器巷查。MySQL查詢分析的利器，就似乎其自帶的"MySQL Optimizer Trace"抹腿。另外岛请，還必須對(duì)MySQL的查詢執(zhí)行過(guò)程有一個(gè)基本了解，特別是排序過(guò)程警绩。

3.1 Optimizer Trace 使用簡(jiǎn)介

Optimizer Trace 是MySQL 5.6.3里新加的一個(gè)特性崇败，可以把MySQL Optimizer的決策和執(zhí)行過(guò)程輸出成文本，結(jié)果為JSON格式，兼顧了程序分析和閱讀的便利后室。

【使用方法】

啟用Optimizer Trace缩膝，它默認(rèn)是關(guān)閉的。
SET optimizer_trace="enabled=on";
設(shè)置Trace使用的內(nèi)存岸霹，默認(rèn)內(nèi)存比較小疾层，有時(shí)候不夠用:
SET optimizer_trace_max_mem_size=1024000;
執(zhí)行SQL語(yǔ)句
SQL_1: SELECT * FROM t ORDER BY a1 DESC LIMIT 100000,1;
SQL_2: SELECT * FROM t INNER JOIN (SELECT a0, a1 FROM t ORDER BY a1 DESC LIMIT 100000,1) AS A USING (a0, a1);
查看Trace輸出
select trace from information_schema.optimizer_trace\G

Trace輸出分為3大部分，如下松申，分別對(duì)應(yīng)到mysql中的三個(gè)函數(shù)： JOIN::prepare(), JOIN::optimize(), JOIN::exec()

{
    trace: {
        steps: [
            { join_preparation: {} },   <--> JOIN::prepare()
            { join_optimization: {} },  <--> JOIN::optiomize()
            { join_execution: {}    }   <--> JOIN::exec()
        ]
    }
}

【系統(tǒng)參數(shù)】
追蹤行為完全由OPTIMIZER_TRACE系列參數(shù)控制云芦，關(guān)于這些參數(shù)的詳細(xì)說(shuō)明參考MySQL在線文檔。

#  show variables like '%optimizer_trace%';
+------------------------------+----------------------------------------------------------------------------+
| Variable_name                | Value                                                                      |
+------------------------------+----------------------------------------------------------------------------+
| optimizer_trace              | enabled=off,one_line=off                                                   |
| optimizer_trace_features     | greedy_search=on,range_optimizer=on,dynamic_range=on,repeated_subselect=on |
| optimizer_trace_limit        | 1                                                                          |
| optimizer_trace_max_mem_size | 16384                                                                      |
| optimizer_trace_offset       | -1                                                                         |
+------------------------------+----------------------------------------------------------------------------+

一般只要關(guān)心optimizer_trace/optimizer_trace_max_mem_size這兩個(gè)參數(shù)贸桶。optimizer_trace可以開啟和關(guān)閉追蹤舅逸，結(jié)果打印方式等，optimizer_trace_max_mem_size決定追蹤工具最多可以使用多少內(nèi)容皇筛。

optimizer_trace    enabled=on  啟用追蹤
                   enabled=off 不啟用追蹤
                   one_line=on TRACE輸出在一行里面琉历，便于程序處理
                   one_line=off TRACE輸出在多行，便于閱讀
optimizer_trace_max_mem_size   追蹤時(shí)最多允許使用多少內(nèi)存水醋，內(nèi)存太小可能輸出不完整旗笔。

這些參數(shù)都是基于SESSION的，并且optimizer_trace默認(rèn)情況下沒(méi)有開啟拄踪，使用起來(lái)很安全蝇恶。隨后的章節(jié)會(huì)有詳細(xì)實(shí)用案例，此處不再贅述惶桐。

3.2 MySQL排序簡(jiǎn)介

對(duì)于MySQL排序有篇文章寫的不錯(cuò)：MySQL排序內(nèi)部原理探秘, 也可以閱讀MySQL源代碼的filesort.cc撮弧。這里挑選幾個(gè)重點(diǎn)列舉下：

MySQL會(huì)把需要排序的數(shù)據(jù)從磁盤讀取到"Sort_buffer"。放到Sort_buffer的字段由 max_length_for_sort_data 決定：
a) 字段總長(zhǎng)度>max_length_for_sort_data姚糊，讀取"排序字段+RowID"贿衍。這種方式稱為回表模式，記為：< sort_key,rowid>
b) 字段總長(zhǎng)度<=max_length_for_sort_data救恨，讀取"排序字段+SELECT字段+WHERE字段"贸辈。這種方式稱為不回表模式，記為：<sort_key,additional_fields>
Sort_buffer有大小限制肠槽，在我們的場(chǎng)景中擎淤，是8MB。
數(shù)據(jù)量超過(guò)Sort_buffer時(shí)秸仙，會(huì)初步排序揉燃，然后寫入外部臨時(shí)表。
若使用了臨時(shí)表筋栋，通過(guò)"多路歸并排序"逐步合并，直到最后輸出有序結(jié)果正驻。
使用了臨時(shí)表時(shí)弊攘，查詢性能一般來(lái)說(shuō)會(huì)急劇下降抢腐。
對(duì)于帶Order By+Limit的語(yǔ)句，會(huì)進(jìn)行"優(yōu)先隊(duì)列"評(píng)估襟交，如果適用迈倍，可以只取若干元素，加速排序捣域。

優(yōu)先隊(duì)列評(píng)估 是非常重要的一個(gè)步驟啼染，對(duì)TopN查詢性能提升很大，過(guò)程簡(jiǎn)要描述如下：

* 估算數(shù)據(jù)表的數(shù)據(jù)總量上限 N
* 計(jì)算需要返回的數(shù)據(jù)總量 M = (LIMIT + OFFSET)
* 計(jì)算Sort_buffer容量 X
* Case 1: 如果 X > N
    Case 1.1: 如果 M < N / PQ_slowness焕梅，啟用優(yōu)先隊(duì)列
    Case 1.2: 否則迹鹅，不啟用優(yōu)先隊(duì)列，而是直接用快速排序贞言。
* Case 2: 如果 X > M + 1斜棚，啟用優(yōu)先隊(duì)列
* Case 3: 如果當(dāng)前是不回表模式，嘗試去除非排序字段重新計(jì)算Sort_buffer容量 Y该窗，
    Case 3.1 如果 Y > M + 1弟蚀，估算啟用優(yōu)先隊(duì)列+回表模式的代價(jià) C1，估算使用臨時(shí)表多路歸并+不回表模式的代價(jià) C2
        Case 3.1.1: 如果 C1 < C2酗失，啟用優(yōu)先隊(duì)列义钉，并修改為回表模式；
        Case 3.1.2: 否則不啟用優(yōu)先隊(duì)列规肴。
* Final: 各條件不滿足捶闸，不啟用優(yōu)先隊(duì)列。

圖3-1 優(yōu)先隊(duì)列評(píng)估過(guò)程

四奏纪、觀察案例中SQL的執(zhí)行

準(zhǔn)備測(cè)試環(huán)境：

#  SHOW variables like '%sort%';
+--------------------------------+---------------------+
| Variable_name                  | Value               |
+--------------------------------+---------------------+
| max_length_for_sort_data       | 1024                |
| sort_buffer_size               | 8388608             |
+--------------------------------+---------------------+

#  SET optimizer_trace="enabled=on";
#  SET optimizer_trace_max_mem_size=1000000;

#  SELECT trace FROM information_schema.optimizer_trace\G

注意兩個(gè)重要變量

max_length_for_sort_data: 1024
sort_buffer_size: 8388608

4.1 SQL_1 執(zhí)行過(guò)程

SELECT * FROM t ORDER BY a1 DESC LIMIT 100000,1;

圖4-1 SQL_1 執(zhí)行過(guò)程

解析

* ORDER BY a1, 排序字段a1無(wú)索引鉴嗤，使用全文掃描
* SELECT *, 需要讀取所有字段
* SELECT字段+排序字段+WHERE字段長(zhǎng)度=454，454 < max_length_for_sort_data(1024)序调，使用不回表模式醉锅。
* 查詢中存在Order By+Limit，需進(jìn)行優(yōu)先隊(duì)列評(píng)估
    Case 1 不滿足: 1850799*454 > 8388608
    Case 2 不滿足: 100001*454 > 8388608
    Case 3.1 滿足: 74*(100001+1) < 8388608
        計(jì)算PQ代價(jià) C1 = 1.18e9
        計(jì)算外排代價(jià) C2 = 3.04e6
        C1 > C2发绢，優(yōu)先隊(duì)列得不償失硬耍，不啟用
* 執(zhí)行結(jié)果：無(wú)優(yōu)先隊(duì)列，不回表模式边酒，使用了46個(gè)臨時(shí)表

4.2 SQL_2 執(zhí)行過(guò)程

SELECT * FROM t INNER JOIN (SELECT a0, a1 FROM t ORDER BY a1 DESC LIMIT 100000,1) AS A USING (a0, a1);

圖4-2 SQL_2 執(zhí)行過(guò)程

解析

*首先執(zhí)行子查詢 SELECT a0, a1 FROM t ORDER BY a1 DESC LIMIT 100000,1
    SELECT a0,a1, 只需要讀取a0和a1兩個(gè)字段
    ORDER BY a1, 排序字段a1無(wú)索引经柴，使用全文掃描
    SELECT字段+排序字段+WHERE字段長(zhǎng)度=66，66 < max_length_for_sort_data(1024)墩朦，使用不回表模式坯认。
    查詢中存在 Order By+Limit，進(jìn)行優(yōu)先隊(duì)列評(píng)估
        Case 1 不滿足: 1850799*66 > 8388608
        Case 2 可滿足: 100001*66 > 8388608
        啟用優(yōu)先隊(duì)列
    執(zhí)行結(jié)果：?jiǎn)⒂脙?yōu)先隊(duì)列，不回表模式牛哺，沒(méi)有使用臨時(shí)表
    執(zhí)行完畢陋气，結(jié)果存儲(chǔ)在臨時(shí)表A里面
* 臨時(shí)表A只有1行，連表查詢時(shí)引润，可以使用 t 的主鍵巩趁，非常快速淳附。

4.3 小結(jié)

全表掃描時(shí)议慰，SQL_1需要讀取所有字段（大約500字節(jié)），SQL_2只需要讀取2個(gè)字段（小于100字節(jié)）奴曙。
SQL1需要使用外部排序别凹，臨時(shí)表數(shù)量又比較多（46個(gè)），所以比較慢缆毁。
SQL2可以啟用優(yōu)先隊(duì)列優(yōu)化番川，排序用數(shù)據(jù)全部存放在sort_buffer，加速明顯脊框。

五颁督、場(chǎng)景擴(kuò)展

5.1 Limit 大小對(duì)執(zhí)行過(guò)程的影響

稍微修改下SQL語(yǔ)句，把 LIMIT 100000,1 修改為 LIMIT 600000,1浇雹，再看執(zhí)行過(guò)程沉御。

5.1.1 SQL_1 執(zhí)行過(guò)程

SELECT * FROM t ORDER BY a1 DESC LIMIT 600000,1;
1 row in set (8.82 sec)

圖5-1 Limit 600000 時(shí) SQL_1 執(zhí)行過(guò)程

解析
這次的執(zhí)行結(jié)果和4.1完全一樣，還是"無(wú)優(yōu)先隊(duì)列+不會(huì)表模式"昭灵，但決策依據(jù)稍有不同：(600001+1)*74 > 8388608吠裆，Case 3.1不滿足，而之前是Case 3.1.1不滿足烂完。

5.1.2 SQL_2 執(zhí)行過(guò)程

SELECT * FROM t INNER JOIN (SELECT a0, a1 FROM t ORDER BY a1 DESC LIMIT 600000,1) AS A USING (a0, a1);
1 row in set (1.05 sec)

圖5-2 Limit 600000 時(shí) SQL_2 執(zhí)行過(guò)程

解析

這次查詢比4.2慢试疙，因?yàn)镃ase 2和Case 3.1都不滿足，未啟用優(yōu)先隊(duì)列抠蚣，使用"無(wú)優(yōu)先隊(duì)列+不回表模式"祝旷。
但是和5.1.1相比，子查詢的數(shù)據(jù)總量變少嘶窄，只使用了8個(gè)臨時(shí)表怀跛，還是更快。

5.2 回表排序的影響

以上測(cè)試柄冲，都是不回表模式吻谋，如果是回表模式，會(huì)怎么樣呢现横？先把關(guān)鍵參數(shù)設(shè)置更小漓拾，迫使MySQL使用回表模式：SET max_length_for_sort_data=100;

5.2.1 SQL_1 執(zhí)行過(guò)程

SELECT * FROM t ORDER BY a1 DESC LIMIT 600000,1;
1 row in set (4.16 sec)

解析

因?yàn)?SELECT字段+排序字段+WHERE字段)(454字節(jié)) > max_length_for_sort_data(100)阁最，這次使用了回表模式，但還是無(wú)法啟用優(yōu)先隊(duì)列優(yōu)化骇两。
因?yàn)榕判驎r(shí)只需要讀取排序字段和rowid闽撤，臨時(shí)表數(shù)量減少到8個(gè)。

5.2.2 SQL_2 執(zhí)行過(guò)程

SELECT * FROM t INNER JOIN (SELECT a0, a1 FROM t ORDER BY a1 DESC LIMIT 600000,1) AS A USING (a0, a1);
1 row in set (1.05 sec)

解析
由于(SELECT字段+排序字段+WHERE字段)(66字節(jié)) < max_length_for_sort_data(100)脯颜，依然還是"無(wú)優(yōu)先隊(duì)列+不回表模式""，使用了8個(gè)臨時(shí)表贩据。

六栋操、參考資料

MySQL: The Optimizer Trace

MySQL: Tracing the Optimizer
MySQL: Optimizing SELECT Statements
Using delayed JOIN to optimize count and LIMIT queries
MySQL排序內(nèi)部原理探秘
MySQL Server 5.6.34 Source Code
高性能 MySQL 3rd Edition

最后編輯于：2017.12.06 05:52:57

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者

人面猴
序言：七十年代末，一起剝皮案震驚了整個(gè)濱河市饱亮，隨后出現(xiàn)的幾起案子矾芙，更是在濱河造成了極大的恐慌，老刑警劉巖近上，帶你破解...
沈念sama閱讀 211,042評(píng)論 6贊 490
死咒
序言：濱河連續(xù)發(fā)生了三起死亡事件剔宪，死亡現(xiàn)場(chǎng)離奇詭異，居然都是意外死亡壹无，警方通過(guò)查閱死者的電腦和手機(jī)葱绒，發(fā)現(xiàn)死者居然都...
沈念sama閱讀 89,996評(píng)論 2贊 384
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái)斗锭，“玉大人地淀，你說(shuō)我怎么就攤上這事♂牵” “怎么了帮毁？”我有些...
開封第一講書人閱讀 156,674評(píng)論 0贊 345
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵，是天一觀的道長(zhǎng)豺撑。經(jīng)常有香客問(wèn)我烈疚，道長(zhǎng)，這世上最難降的妖魔是什么聪轿？我笑而不...
開封第一講書人閱讀 56,340評(píng)論 1贊 283
?港島之戀（遺憾婚禮）
正文為了忘掉前任爷肝，我火速辦了婚禮，結(jié)果婚禮上屹电，老公的妹妹穿的比我還像新娘阶剑。我一直安慰自己，他們只是感情好危号，可當(dāng)我...
茶點(diǎn)故事閱讀 65,404評(píng)論 5贊 384
惡毒庶女頂嫁案：這布局不是一般人想出來(lái)的
文/花漫我一把揭開白布牧愁。她就那樣靜靜地躺著，像睡著了一般外莲。火紅的嫁衣襯著肌膚如雪猪半。梳的紋絲不亂的頭發(fā)上兔朦，一...
開封第一講書人閱讀 49,749評(píng)論 1贊 289
城市分裂傳說(shuō)
那天，我揣著相機(jī)與錄音磨确，去河邊找鬼沽甥。笑死，一個(gè)胖子當(dāng)著我的面吹牛乏奥，可吹牛的內(nèi)容都是我干的摆舟。我是一名探鬼主播，決...
沈念sama閱讀 38,902評(píng)論 3贊 405
雙鴛鴦連環(huán)套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼邓了，長(zhǎng)吁一口氣：“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼恨诱！你這毒婦竟也來(lái)了？” 一聲冷哼從身側(cè)響起骗炉，我...
開封第一講書人閱讀 37,662評(píng)論 0贊 266
萬(wàn)榮殺人案實(shí)錄
序言：老撾萬(wàn)榮一對(duì)情侶失蹤照宝，失蹤者是張志新（化名）和其女友劉穎，沒(méi)想到半個(gè)月后句葵，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體厕鹃，經(jīng)...
沈念sama閱讀 44,110評(píng)論 1贊 303
?護(hù)林員之死
正文獨(dú)居荒郊野嶺守林人離奇死亡，尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛以下內(nèi)容為張勛視角年9月15日...
茶點(diǎn)故事閱讀 36,451評(píng)論 2贊 325
?白月光啟示錄
正文我和宋清朗相戀三年乍丈，在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了剂碴。大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
茶點(diǎn)故事閱讀 38,577評(píng)論 1贊 340
活死人
序言：一個(gè)原本活蹦亂跳的男人離奇死亡诗赌，死狀恐怖汗茄，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情铭若，我是刑警寧澤洪碳，帶...
沈念sama閱讀 34,258評(píng)論 4贊 328
?日本核電站爆炸內(nèi)幕
正文年R本政府宣布，位于F島的核電站叼屠，受9級(jí)特大地震影響瞳腌，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜镜雨，卻給世界環(huán)境...
茶點(diǎn)故事閱讀 39,848評(píng)論 3贊 312
男人毒藥：我在死后第九天來(lái)索命
文/蒙蒙一嫂侍、第九天我趴在偏房一處隱蔽的房頂上張望。院中可真熱鬧荚坞，春花似錦挑宠、人聲如沸。這莊子的主人今日做“春日...
開封第一講書人閱讀 30,726評(píng)論 0贊 21
一樁弒父案各淀，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽(yáng)。三九已至诡挂，卻和暖如春碎浇，著一層夾襖步出監(jiān)牢的瞬間临谱，已是汗流浹背。一陣腳步聲響...
開封第一講書人閱讀 31,952評(píng)論 1贊 264
情欲美人皮
我被黑心中介騙來(lái)泰國(guó)打工奴璃，沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留悉默，地道東北人。一個(gè)月前我還...
沈念sama閱讀 46,271評(píng)論 2贊 360
代替公主和親
正文我出身青樓苟穆，卻偏偏與公主長(zhǎng)得像抄课，于是被迫代替她去往敵國(guó)和親。傳聞我的和親對(duì)象是個(gè)殘疾皇子雳旅，可洞房花燭夜當(dāng)晚...
茶點(diǎn)故事閱讀 43,452評(píng)論 2贊 348