MySQL的SQL優(yōu)化

通過 show status 命令了解各種 SQL 的執(zhí)行頻率

Com_select：執(zhí)行 select 操作的次數(shù)总处，一次查詢只累加 1基茵。

Com_insert：執(zhí)行 INSERT 操作的次數(shù)，對于批量插入的 INSERT 操作，只累加一次。

Com_update：執(zhí)行 UPDATE 操作的次數(shù)。

Com_delete：執(zhí)行 DELETE 操作的次數(shù)亿鲜。

上面這些參數(shù)對于所有存儲引擎的表操作都會進(jìn)行累計。下面這幾個參數(shù)只是針對

InnoDB 存儲引擎的冤吨，累加的算法也略有不同蒿柳。

Innodb_rows_read：select 查詢返回的行數(shù)。

Innodb_rows_inserted：執(zhí)行 INSERT 操作插入的行數(shù)漩蟆。

Innodb_rows_updated：執(zhí)行 UPDATE 操作更新的行數(shù)垒探。

Innodb_rows_deleted：執(zhí)行 DELETE 操作刪除的行數(shù)。

通過 EXPLAIN 分析低效 SQL 的執(zhí)行計劃

mysql> explain select sum(moneys) from sales a,company b where a.company_id = b.id and a.year
= 2006\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: a
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 1000
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: b
type: ref
possible_keys: ind_company_id
key: ind_company_id
key_len: 5
ref: sakila.a.company_id
rows: 1
Extra: Using where; Using index
2 rows in set (0.00 sec)

select_type：表示 SELECT 的類型怠李，常見的取值有 SIMPLE（簡單表圾叼，即不使用表連接或者子查詢）、PRIMARY（主查詢捺癞，即外層的查詢）夷蚊、UNION（UNION 中的第二個或者后面的查詢語句）、SUBQUERY（子查詢中的第一個 SELECT）等髓介。

table：輸出結(jié)果集的表惕鼓。

type：表示表的連接類型，性能由好到差的連接類型為 system（表中僅有一行版保，即常量表）呜笑、const（單表中最多有一個匹配行夫否，例如 primary key 或者 unique index）彻犁、eq_ref（對于前面的每一行，在此表中只查詢一條記錄凰慈，簡單來說汞幢，就是多表連接中使用primary key或者unique index）、ref （與eq_ref類似微谓，區(qū)別在于不是使用primarykey 或者 unique index森篷，而是使用普通的索引）输钩、ref_or_null（與 ref 類似，區(qū)別在于條件中包含對 NULL 的查詢）index_merge(索引合并優(yōu)化)仲智、unique_subquery（in的后面是一個查詢主鍵字段的子查詢）买乃、index_subquery （與 unique_subquery 類似，區(qū)別在于 in 的后面是查詢非唯一索引字段的子查詢）钓辆、range（單表中的范圍查詢）剪验、index（對于前面的每一行，都通過查詢索引來得到數(shù)據(jù)）前联、all （對于前面的每一行功戚，都通過全表掃描來得到數(shù)據(jù)）。

possible_keys：表示查詢時似嗤，可能使用的索引啸臀。

key：表示實(shí)際使用的索引。

key_len：索引字段的長度烁落。

rows：掃描行的數(shù)量乘粒。

Extra：執(zhí)行情況的說明和描述。

在上面的例子中伤塌，已經(jīng)可以確認(rèn)是對 a 表的全表掃描導(dǎo)致效率的不理想谓厘，那么對 a 表的year 字段創(chuàng)建索引，具體如下：

mysql> create index ind_sales2_year on sales2(year);
Query OK, 1000 rows affected (0.03 sec)
Records: 1000 Duplicates: 0 Warnings: 0

mysql> explain select sum(moneys) from sales2 a,company2 b where a.company_id = b.id and
a.year = 2006\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: a
type: ref
possible_keys: ind_sales2_year
key: ind_sales2_year
key_len: 2
ref: const
rows: 1
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: b
type: ref
possible_keys: ind_company2_id
key: ind_company2_id
key_len: 5
ref: sakila.a.company_id
rows: 1
Extra: Using where; Using index
2 rows in set (0.00 sec)

可以發(fā)現(xiàn)建立索引后對 a 表需要掃描的行數(shù)明顯減少（從 1000 行減少到 1 行）寸谜，可見索引的使用可以大大提高數(shù)據(jù)庫的訪問速度竟稳，尤其在表很龐大的時候這種優(yōu)勢更為明顯。

索引問題

MySQL 中索引的存儲類型目前只有兩種（BTREE 和 HASH）熊痴，具體和表的存儲引擎相關(guān)：MyISAM 和 InnoDB 存儲引擎都只支持 BTREE 索引他爸；MEMORY/HEAP 存儲引擎可以支持 HASH和 BTREE 索引

MySQL 目前不支持函數(shù)索引，但是能對列的前面某一部分進(jìn)索引

mysql> create index ind_company2_name on company2(name(4));
Query OK, 1000 rows affected (0.03 sec)
Records: 1000 Duplicates: 0 Warnings: 0

使用索引

1.對于創(chuàng)建的多列索引果善，只要查詢的條件中用到了最左邊的列诊笤，索引一般就會被使用，舉例說明如下巾陕。

mysql> create index ind_sales2_companyid_moneys on sales2(company_id,moneys);
Query OK, 1000 rows affected (0.03 sec)
Records: 1000 Duplicates: 0 Warnings: 0

--然后按 company_id 進(jìn)行表查詢讨跟，具體如下：
mysql> explain select * from sales2 where company_id = 2006\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: sales2
type: ref
possible_keys: ind_sales2_companyid_moneys
key: ind_sales2_companyid_moneys
key_len: 5
ref: const
rows: 1
Extra: Using where
1 row in set (0.00 sec)

--可以發(fā)現(xiàn)即便 where 條件中不是用的 company_id 與 moneys 的組合條件，索引仍然能用到鄙煤，這就是索引的前綴特性晾匠。但是如果只按 moneys 條件查詢表，那么索引就不會被用到梯刚，具體如下：
mysql> explain select * from sales2 where moneys = 1\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: sales2
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 1000
Extra: Using where
1 row in set (0.00 sec)

2.對于使用 like 的查詢凉馆，后面如果是常量并且只有％號不在第一個字符，索引才可能會被使用，來看下面兩個執(zhí)行計劃：

mysql> explain select * from company2 where name like '%3'\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: company2
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 1000
Extra: Using where
1 row in set (0.00 sec)
mysql> explain select * from company2 where name like '3%'\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: company2
type: range
possible_keys: ind_company2_name
key: ind_company2_name
key_len: 11
ref: NULL
rows: 103
Extra: Using where
1 row in set (0.00 sec)

3.如果對大的文本進(jìn)行搜索澜共，使用全文索引而不用使用 like ‘%…%’向叉。

4.如果列名是索引，使用 column_name is null 將使用索引嗦董。如下例中查詢 name 為 null的記錄就用到了索引：

mysql> explain select * from company2 where name is null\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: company2
type: ref
possible_keys: ind_company2_name
key: ind_company2_name
key_len: 11
ref: const
rows: 1
Extra: Using where
1 row in set (0.00 sec)

存在索引但不使用索引

1.如果 MySQL 估計使用索引比全表掃描更慢母谎，則不使用索引。例如如果列
key_part1 均勻分布在 1 和 100 之間京革，下列查詢中使用索引就不是很好：

SELECT * FROM table_name where key_part1 > 1 and key_part1 < 90;

2.如果使用 MEMORY/HEAP 表并且 where 條件中不使用“=”進(jìn)行索引列销睁，那么
不會用到索引。heap 表只有在“=”的條件下才會使用索引存崖。

3.用 or分割開的條件冻记，如果 or前的條件中的列有索引，而后面的列中沒有索引来惧，
那么涉及到的索引都不會被用到冗栗，例如：

mysql> show index from sales\G;
*************************** 1. row ***************************
Table: sales
Non_unique: 1
Key_name: ind_sales_year
Seq_in_index: 1
Collation: A
Cardinality: NULL
Sub_part: NULL
Packed: NULL
Null:
Index_type: BTREE
Comment:
1 row in set (0.00 sec)
Column_name: year
--從上面可以發(fā)現(xiàn)只有 year 列上面有索引，來看如下的執(zhí)行計劃：
mysql> explain select * from sales where year = 2001 or country = 'China'\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: sales
type: ALL
possible_keys: ind_sales_year
key: NULL
key_len: NULL
ref: NULL
rows: 12
Extra: Using where
1 row in set (0.00 sec)

4.如果不是索引列的第一部分供搀，如下例子：

mysql> explain select * from sales2 where moneys = 1\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: sales2
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 1000
Extra: Using where
1 row in set (0.00 sec)
--可見雖然在 money 上面建有復(fù)合索引隅居，但是由于 money 不是索引的第一列，那么在查詢中這個索引也不會被 MySQL 采用葛虐。

5.如果 like 是以％開始

6.如果列類型是字符串胎源，那么一定記得在 where 條件中把字符常量值用引號引
起來，否則的話即便這個列上有索引屿脐，MySQL 也不會用到的涕蚤，因為，MySQL 默認(rèn)把輸入的常量值進(jìn)行轉(zhuǎn)換以后才進(jìn)行檢索的诵。如下面的例子中company2表中的name字段是字符型的万栅，但是 SQL 語句中的條件值 294 是一個數(shù)值型值，因此即便在 name 上有索引西疤，MySQL 也不能正確地用上索引烦粒，而是繼續(xù)進(jìn)行全表掃描。

mysql> explain select * from company2 where name = 294\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: company2
type: ALL
possible_keys: ind_company2_name
key: NULL
key_len: NULL
ref: NULL
rows: 1000
Extra: Using where
1 row in set (0.00 sec)
mysql> explain select * from company2 where name = '294'\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: company2
type: ref
possible_keys: ind_company2_name
key: ind_company2_name
key_len: 23
ref: const
rows: 1
Extra: Using where
1 row in set (0.00 sec)

查看索引使用情況

如果索引正在工作代赁，Handler_read_key 的值將很高扰她，這個值代表了一個行被索引值讀的次數(shù)，很低的值表明增加索引得到的性能改善不高芭碍，因為索引并不經(jīng)常使用徒役。
Handler_read_rnd_next 的值高則意味著查詢運(yùn)行低效，并且應(yīng)該建立索引補(bǔ)救豁跑。這個值的含義是在數(shù)據(jù)文件中讀下一行的請求數(shù)廉涕。如果正進(jìn)行大量的表掃描泻云，Handler_read_rnd_next 的值較高艇拍，則通常說明表索引不正確或?qū)懭氲牟樵儧]有利用索引狐蜕，具體如下。

mysql> show status like 'Handler_read%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Handler_read_first | 0 |
| Handler_read_key | 5 |
| Handler_read_next | 0 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 2055 |
+-----------------------+-------+
6 rows in set (0.00 sec)

兩個簡單實(shí)用的優(yōu)化方法

1.定期分析表和檢查表

分析的結(jié)果將可以使得系統(tǒng)得到準(zhǔn)確的統(tǒng)計信息卸夕，使得 SQL 能夠生成正確的執(zhí)行計劃层释。

--分析表的語法如下：
ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...

mysql> analyze table sales;
+--------------+---------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+--------------+---------+----------+----------+
| sakila.sales | analyze | status | OK |
+--------------+---------+----------+----------+
1 row in set (0.00 sec)

--檢查表的語法如下：
CHECK TABLE tbl_name [, tbl_name] ... [option] ... option = {QUICK | FAST | MEDIUM | EXTENDED
| CHANGED}

--檢查表的作用是檢查一個或多個表是否有錯誤。CHECK TABLE對MyISAM和InnoDB表有作用快集。對于 MyISAM 表贡羔，關(guān)鍵字統(tǒng)計數(shù)據(jù)被更新，例如：
mysql> check table sales;
+--------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+--------------+-------+----------+----------+
| sakila.sales | check | status | OK |
+--------------+-------+----------+----------+
1 row in set (0.00 sec)

CHECK TABLE 也可以檢查視圖是否有錯誤个初，比如在視圖定義中被引用的表已不存在乖寒，舉例如下

--1）首先我們創(chuàng)建一個視圖
mysql> create view sales_view3 as select * from sales3;
Query OK, 0 rows affected (0.00 sec)

--2）然后 CHECK 一下該視圖，發(fā)現(xiàn)沒有問題院溺。
mysql> check table sales_view3;
+--------------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+--------------------+-------+----------+----------+
| sakila.sales_view3 | check | status | OK |
+--------------------+-------+----------+----------+
1 row in set (0.00 sec)

--3）現(xiàn)在刪除掉視圖依賴的表
mysql> drop table sales3;
Query OK, 0 rows affected (0.00 sec)

--4）再來 CHECK 一下剛才的視圖楣嘁，發(fā)現(xiàn)報錯了
mysql> check table sales_view3\G;
*************************** 1. row ***************************
Table: sakila.sales_view3
Op: check
Msg_type: error
Msg_text: View 'sakila.sales_view3' references invalid table(s) or column(s) or function(s)
or definer/invoker of view lack rights to use them
1 row in set (0.00 sec)

2.定期優(yōu)化表

優(yōu)化表的語法如下：

OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...

如果已經(jīng)刪除了表的一大部分，或者如果已經(jīng)對含有可變長度行的表（含有 VARCHAR珍逸、BLOB 或 TEXT 列的表）進(jìn)行了很多更改逐虚，則應(yīng)使用 OPTIMIZE TABLE 命令來進(jìn)行表優(yōu)化。這個命令可以將表中的空間碎片進(jìn)行合并谆膳，并且可以消除由于刪除或者更新造成的空間浪費(fèi)叭爱，但OPTIMIZE TABLE 命令只對 MyISAM、BDB 和 InnoDB 表起作用漱病。

mysql> optimize table sales;
+--------------+----------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+--------------+----------+----------+----------+
| sakila.sales | optimize | status | OK |
+--------------+----------+----------+----------+
1 row in set (0.00 sec)

常用 SQL 的優(yōu)化

優(yōu)化 GROUP BY 語句

如果查詢包括 GROUP BY 但用戶想要避免排序結(jié)果的消耗买雾，則可以指定 ORDER BY NULL
禁止排序，如下面的例子：

mysql> explain select id,sum(moneys) from sales2 group by id\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: sales2
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 1000
Extra: Using temporary; Using filesort
1 row in set (0.00 sec)
mysql> explain select id,sum(moneys) from sales2 group by id order by null\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: sales2
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 1000
Extra: Using temporary
1 row in set (0.00 sec)

從上面的例子可以看出第一個SQL語句需要進(jìn)行“filesort”杨帽，而第二個SQL由于ORDER BY NULL不需要進(jìn)行“filesort”凝果，而 filesort 往往非常耗費(fèi)時間。

優(yōu)化 ORDER BY 語句：

在某些情況中睦尽，MySQL 可以使用一個索引來滿足 ORDER BY 子句器净，而不需要額外的排序。WHERE 條件和 ORDER BY 使用相同的索引当凡，并且 ORDER BY 的順序和索引順序相同山害，并且ORDER BY 的字段都是升序或者都是降序。
例如沿量，下列 SQL 可以使用索引浪慌。

SELECT * FROM t1 ORDER BY key_part1,key_part2,... ;
SELECT * FROM t1 WHERE key_part1=1 ORDER BY key_part1 DESC, key_part2 DESC;
SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 DESC;

但是在以下幾種情況下則不使用索引：

SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 ASC；
--order by 的字段混合 ASC 和 DESC
SELECT * FROM t1 WHERE key2=constant ORDER BY key1朴则；
--用于查詢行的關(guān)鍵字與 ORDER BY 中所使用的不相同
SELECT * FROM t1 ORDER BY key1, key2权纤；
--對不同的關(guān)鍵字使用 ORDER BY：

優(yōu)化嵌套查詢

有些情況下，子查詢可以被更有效率的連接（JOIN）替代

mysql> explain select * from sales2 where company_id not in ( select id from
company2 )\G;
*************************** 1. row ***************************
id: 1
select_type: PRIMARY
table: sales2
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 1000
Extra: Using where
*************************** 2. row ***************************
id: 2
select_type: DEPENDENT SUBQUERY
table: company2
type: index_subquery
possible_keys: ind_company2_id
key: ind_company2_id
key_len: 5
ref: func
rows: 2
Extra: Using index
2 rows in set (0.00 sec)

如果使用連接（JOIN）來完成這個查詢工作，速度將會快很多汹想。尤其是當(dāng) company2 表
中對 id 建有索引的話外邓，性能將會更好，具體查詢?nèi)缦拢?/p>

mysql> explain select * from sales2 left join company2 on sales2.company_id =
company2.id where sales2.company_id is null\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: sales2
type: ref
possible_keys: ind_sales2_companyid_moneys
key: ind_sales2_companyid_moneys
key_len: 5
ref: const
rows: 1
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: company2
type: ref
possible_keys: ind_company2_id
key: ind_company2_id
key_len: 5
ref: sakila.sales2.company_id
rows: 1
Extra:
2 rows in set (0.00 sec)

連接（JOIN）之所以更有效率一些古掏，是因為 MySQL 不需要在內(nèi)存中創(chuàng)建臨時表來完成這
個邏輯上的需要兩個步驟的查詢工作损话。

MySQL 如何優(yōu)化 OR 條件

對于含有 OR 的查詢子句，如果要利用索引槽唾，則 OR 之間的每個條件列都必須用到索引丧枪；
如果沒有索引，則應(yīng)該考慮增加索引庞萍。
例如拧烦，首先使用 show index 命令查看表 sales2 的索引，可知它有 3 個索引钝计，在 id恋博、year
兩個字段上分別有 1 個獨(dú)立的索引，在 company_id 和 year 字段上有 1 個復(fù)合索引葵蒂。

--然后在兩個獨(dú)立索引上面做 OR 操作交播，具體如下：
mysql> explain select * from sales2 where id = 2 or year = 1998\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: sales2
type: index_merge
possible_keys: ind_sales2_id,ind_sales2_year
key: ind_sales2_id,ind_sales2_year
key_len: 5,2
ref: NULL
rows: 2
Extra: Using union(ind_sales2_id,ind_sales2_year); Using where
1 row in set (0.00 sec)

可以發(fā)現(xiàn)查詢正確的用到了索引，并且從執(zhí)行計劃的描述中践付，發(fā)現(xiàn) MySQL 在處理含有 OR
字句的查詢時秦士，實(shí)際是對 OR 的各個字段分別查詢后的結(jié)果進(jìn)行了 UNION。
但是當(dāng)在建有復(fù)合索引的列company_id 和 moneys上面做 OR 操作的時候永高，卻不能用到索引隧土，具體結(jié)果如下：

mysql> explain select * from sales2 where company_id = 3 or moneys = 100\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: sales2
type: ALL
possible_keys: ind_sales2_companyid_moneys
key: NULL
key_len: NULL
ref: NULL
rows: 1000
Extra: Using where
1 row in set (0.00 sec)

最后編輯于：2017.12.08 01:12:14

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

人面猴
序言：七十年代末，一起剝皮案震驚了整個濱河市命爬，隨后出現(xiàn)的幾起案子曹傀，更是在濱河造成了極大的恐慌，老刑警劉巖饲宛，帶你破解...
沈念sama閱讀 212,383評論 6贊 493
死咒
序言：濱河連續(xù)發(fā)生了三起死亡事件皆愉，死亡現(xiàn)場離奇詭異，居然都是意外死亡艇抠，警方通過查閱死者的電腦和手機(jī)幕庐，發(fā)現(xiàn)死者居然都...
沈念sama閱讀 90,522評論 3贊 385
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來家淤，“玉大人异剥，你說我怎么就攤上這事⌒踔兀” “怎么了冤寿？”我有些...
開封第一講書人閱讀 157,852評論 0贊 348
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵歹苦，是天一觀的道長。經(jīng)常有香客問我督怜，道長殴瘦，這世上最難降的妖魔是什么？我笑而不...
開封第一講書人閱讀 56,621評論 1贊 284
?港島之戀（遺憾婚禮）
正文為了忘掉前任亮蛔，我火速辦了婚禮痴施，結(jié)果婚禮上擎厢，老公的妹妹穿的比我還像新娘究流。我一直安慰自己，他們只是感情好动遭，可當(dāng)我...
茶點(diǎn)故事閱讀 65,741評論 6贊 386
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布芬探。她就那樣靜靜地躺著，像睡著了一般厘惦。火紅的嫁衣襯著肌膚如雪偷仿。梳的紋絲不亂的頭發(fā)上，一...
開封第一講書人閱讀 49,929評論 1贊 290
城市分裂傳說
那天宵蕉，我揣著相機(jī)與錄音酝静，去河邊找鬼。笑死羡玛，一個胖子當(dāng)著我的面吹牛别智，可吹牛的內(nèi)容都是我干的。我是一名探鬼主播稼稿，決...
沈念sama閱讀 39,076評論 3贊 410
雙鴛鴦連環(huán)套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼薄榛，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了让歼？” 一聲冷哼從身側(cè)響起敞恋，我...
開封第一講書人閱讀 37,803評論 0贊 268
萬榮殺人案實(shí)錄
序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎谋右，沒想到半個月后硬猫，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
沈念sama閱讀 44,265評論 1贊 303
?護(hù)林員之死
正文獨(dú)居荒郊野嶺守林人離奇死亡改执，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內(nèi)容為張勛視角年9月15日...
茶點(diǎn)故事閱讀 36,582評論 2贊 327
?白月光啟示錄
正文我和宋清朗相戀三年啸蜜，在試婚紗的時候發(fā)現(xiàn)自己被綠了。大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片天梧。...
茶點(diǎn)故事閱讀 38,716評論 1贊 341
活死人
序言：一個原本活蹦亂跳的男人離奇死亡盔性，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出呢岗，到底是詐尸還是另有隱情冕香，我是刑警寧澤蛹尝，帶...
沈念sama閱讀 34,395評論 4贊 333
?日本核電站爆炸內(nèi)幕
正文年R本政府宣布，位于F島的核電站悉尾，受9級特大地震影響突那，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜构眯，卻給世界環(huán)境...
茶點(diǎn)故事閱讀 40,039評論 3贊 316
男人毒藥：我在死后第九天來索命
文/蒙蒙一愕难、第九天我趴在偏房一處隱蔽的房頂上張望。院中可真熱鬧惫霸，春花似錦猫缭、人聲如沸。這莊子的主人今日做“春日...
開封第一講書人閱讀 30,798評論 0贊 21
一樁弒父案猜丹，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽。三九已至硅卢，卻和暖如春射窒，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背将塑。一陣腳步聲響...
開封第一講書人閱讀 32,027評論 1贊 266
情欲美人皮
我被黑心中介騙來泰國打工脉顿，沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留，地道東北人点寥。一個月前我還...
沈念sama閱讀 46,488評論 2贊 361
代替公主和親
正文我出身青樓艾疟，卻偏偏與公主長得像，于是被迫代替她去往敵國和親开财。傳聞我的和親對象是個殘疾皇子汉柒，可洞房花燭夜當(dāng)晚...
茶點(diǎn)故事閱讀 43,612評論 2贊 350

MySQL的SQL優(yōu)化