MySQL大表優(yōu)化方案

當MySQL單表記錄數(shù)過大時，增刪改查性能都會急劇下降弟断，可以參考以下步驟來優(yōu)化：

單表優(yōu)化

除非單表數(shù)據(jù)未來會一直不斷上漲念祭，否則不要一開始就考慮拆分脯爪，拆分會帶來邏輯、部署就漾、運維的各種復雜度呐能，一般以整型值為主的表在千萬級以下，字符串為主的表在五百萬以下是沒有太大問題的从藤。而事實上很多時候MySQL單表的性能依然有不少優(yōu)化空間催跪，甚至能正常支撐千萬級以上的數(shù)據(jù)量

字段

1锁蠕、盡量使用TINYINT夷野、SMALLINT、MEDIUM_INT作為整數(shù)類型而非INT荣倾，如果非負則加上UNSIGNED
2悯搔、VARCHAR的長度只分配真正需要的空間
3、使用枚舉或整數(shù)代替字符串類型
4舌仍、盡量使用TIMESTAMP而非DATETIME妒貌，
5、單表不要有太多字段铸豁，建議在20以內(nèi)
6灌曙、避免使用NULL字段，很難查詢優(yōu)化且占用額外索引空間
7节芥、用整型來存IP

索引

1在刺、索引并不是越多越好，要根據(jù)查詢有針對性的創(chuàng)建头镊，考慮在WHERE和ORDER BY命令上涉及的列建立索引蚣驼，可根據(jù)EXPLAIN來查看是否用了索引還是全表掃描
2、應盡量避免在WHERE子句中對字段進行NULL值判斷相艇，否則將導致引擎放棄使用索引而進行全表掃描
3颖杏、值分布很稀少的字段不適合建索引，例如”性別”這種只有兩三個值的字段
4坛芽、字符字段只建前綴索引
5留储、字符字段最好不要做主鍵
6、不用外鍵咙轩，由程序保證約束
7欲鹏、盡量不用UNIQUE，由程序保證約束
8臭墨、使用多列索引時主意順序和查詢條件保持一致赔嚎，同時刪除不必要的單列索引

查詢SQL

1、可通過開啟慢查詢?nèi)罩緛碚页鲚^慢的SQL
2、不做列運算：SELECT id WHERE age + 1 = 10尤误，任何對列的操作都將導致表掃描侠畔，它包括數(shù)據(jù)庫教程函數(shù)、計算表達式等等损晤，查詢時要盡可能將操作移至等號右邊
3软棺、sql語句盡可能簡單：一條sql只能在一個cpu運算；大語句拆小語句尤勋，減少鎖時間喘落；一條大sql可以堵死整個庫
4、不用SELECT *
5最冰、OR改寫成IN：OR的效率是n級別瘦棋，IN的效率是log(n)級別，in的個數(shù)建議控制在200以內(nèi)
6暖哨、不用函數(shù)和觸發(fā)器赌朋，在應用程序?qū)崿F(xiàn)
7、避免%xxx式查詢
8篇裁、少用JOIN
9沛慢、使用同類型進行比較，比如用'123'和'123'比达布，123和123比
10团甲、盡量避免在WHERE子句中使用 != 或 <> 操作符，否則將引擎放棄使用索引而進行全表掃描
11黍聂、對于連續(xù)數(shù)值躺苦，使用BETWEEN不用IN：SELECT id FROM t WHERE num BETWEEN 1 AND 5
12、列表數(shù)據(jù)不要拿全表分冈，要使用LIMIT來分頁圾另，每頁數(shù)量也不要太大

引擎

目前廣泛使用的是MyISAM和InnoDB兩種引擎：

MyISAM
MyISAM引擎是MySQL 5.1及之前版本的默認引擎，它的特點是：

1雕沉、不支持行鎖集乔，讀取時對需要讀到的所有表加鎖，寫入時則對表加排它鎖
2坡椒、不支持事務
3扰路、不支持外鍵
4、不支持崩潰后的安全恢復
5倔叼、在表有讀取查詢的同時汗唱，支持往表中插入新紀錄
6、支持BLOB和TEXT的前500個字符索引丈攒，支持全文索引
7哩罪、支持延遲更新索引授霸，極大提升寫入性能
8、對于不會進行修改的表际插，支持壓縮表碘耳，極大減少磁盤空間占用

InnoDB
InnoDB在MySQL 5.5后成為默認索引，它的特點是：

1框弛、支持行鎖辛辨，采用MVCC來支持高并發(fā)
2、支持事務
3瑟枫、支持外鍵
4斗搞、支持崩潰后的安全恢復
5、不支持全文索引

總體來講慷妙，MyISAM適合SELECT密集型的表僻焚，而InnoDB適合INSERT和UPDATE密集型的表

系統(tǒng)調(diào)優(yōu)參數(shù)

sysbench：一個模塊化，跨平臺以及多線程的性能測試工具

iibench-mysql：基于 Java 的 MySQL/Percona/MariaDB 索引進行插入性能測試工具

tpcc-mysql：Percona開發(fā)的TPC-C測試工具

具體的調(diào)優(yōu)參數(shù)內(nèi)容較多景殷，具體可參考官方文檔溅呢，這里介紹一些比較重要的參數(shù)：

back_log：back_log值指出在MySQL暫時停止回答新請求之前的短時間內(nèi)多少個請求可以被存在堆棧中澡屡。也就是說猿挚，如果MySql的連接數(shù)據(jù)達到max_connections時，新來的請求將會被存在堆棧中驶鹉，以等待某一連接釋放資源绩蜻，該堆棧的數(shù)量即back_log，如果等待連接的數(shù)量超過back_log室埋，將不被授予連接資源办绝。可以從默認的50升至500

wait_timeout：數(shù)據(jù)庫連接閑置時間姚淆，閑置連接會占用內(nèi)存資源孕蝉。可以從默認的8小時減到半小時

max_user_connection:最大連接數(shù)腌逢，默認為0無上限降淮，最好設一個合理上限thread_concurrency：并發(fā)線程數(shù)，設為CPU核數(shù)的兩倍

skip_name_resolve：禁止對外部連接進行DNS解析搏讶，消除DNS解析時間佳鳖，但需要所有遠程主機用IP訪問

key_buffer_size：索引塊的緩存大小，增加會提升索引處理速度媒惕，對MyISAM表性能影響最大系吩。對于內(nèi)存4G左右，可設為256M或384M妒蔚，通過查詢show status like'key_read%'穿挨，保證key_reads / key_read_requests在0.1%以下最好

innodb_buffer_pool_size：緩存數(shù)據(jù)塊和索引塊月弛，對InnoDB表性能影響最大。通過查詢show status like 'Innodb_buffer_pool_read%'科盛，保證 (Innodb_buffer_pool_read_requests– Innodb_buffer_pool_reads)/ Innodb_buffer_pool_read_requests越高越好

innodb_additional_mem_pool_size：InnoDB存儲引擎用來存放數(shù)據(jù)字典信息以及一些內(nèi)部數(shù)據(jù)結(jié)構(gòu)的內(nèi)存空間大小尊搬，當數(shù)據(jù)庫對象非常多的時候，適當調(diào)整該參數(shù)的大小以確保所有數(shù)據(jù)都能存放在內(nèi)存中提高訪問效率土涝，當過小的時候佛寿，MySQL會記錄Warning信息到數(shù)據(jù)庫的錯誤日志中，這時就需要該調(diào)整這個參數(shù)大小

innodb_log_buffer_size：InnoDB存儲引擎的事務日志所使用的緩沖區(qū)但壮，一般來說不建議超過32MB

query_cache_size：緩存MySQL中的ResultSet冀泻，也就是一條SQL語句執(zhí)行的結(jié)果集，所以僅僅只能針對select語句蜡饵。當某個表的數(shù)據(jù)有任何任何變化弹渔，都會導致所有引用了該表的select語句在Query Cache中的緩存數(shù)據(jù)失效。所以溯祸，當我們的數(shù)據(jù)變化非常頻繁的情況下肢专，使用Query Cache可能會得不償失。根據(jù)命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))進行調(diào)整焦辅，一般不建議太大博杖，256MB可能已經(jīng)差不多了，大型的配置型靜態(tài)數(shù)據(jù)可適當調(diào)大.

可以通過命令show status like 'Qcache_%'查看目前系統(tǒng)Query catch使用大小

read_buffer_size：MySql讀入緩沖區(qū)大小筷登。對表進行順序掃描的請求將分配一個讀入緩沖區(qū)剃根，MySql會為它分配一段內(nèi)存緩沖區(qū)。如果對表的順序掃描請求非常頻繁前方，可以通過增加該變量值以及內(nèi)存緩沖區(qū)大小提高其性能

sort_buffer_size：MySql執(zhí)行排序使用的緩沖大小狈醉。如果想要增加ORDER BY的速度，首先看是否可以讓MySQL使用索引而不是額外的排序階段惠险。如果不能苗傅，可以嘗試增加sort_buffer_size變量的大小

read_rnd_buffer_size：MySql的隨機讀緩沖區(qū)大小。當按任意順序讀取行時(例如班巩，按照排序順序)渣慕，將分配一個隨機讀緩存區(qū)。進行排序查詢時趣竣，MySql會首先掃描一遍該緩沖摇庙，以避免磁盤搜索，提高查詢速度遥缕，如果需要排序大量數(shù)據(jù)卫袒，可適當調(diào)高該值。但MySql會為每個客戶連接發(fā)放該緩沖空間单匣，所以應盡量適當設置該值夕凝，以避免內(nèi)存開銷過大宝穗。

record_buffer：每個進行一個順序掃描的線程為其掃描的每張表分配這個大小的一個緩沖區(qū)。如果你做很多順序掃描码秉，可能想要增加該值

thread_cache_size：保存當前沒有與連接關聯(lián)但是準備為后面新的連接服務的線程逮矛，可以快速響應連接的線程請求而無需創(chuàng)建新的

table_cache：類似于thread_cache_size，但用來緩存表文件转砖，對InnoDB效果不大须鼎，主要用于MyISAM

升級硬件

Scale up，這個不多說了府蔗，根據(jù)MySQL是CPU密集型還是I/O密集型晋控，通過提升CPU和內(nèi)存、使用SSD姓赤，都能顯著提升MySQL性能

讀寫分離

也是目前常用的優(yōu)化赡译，從庫讀主庫寫，一般不要采用雙主或多主引入很多復雜性不铆，盡量采用文中的其他方案來提高性能蝌焚。同時目前很多拆分的解決方案同時也兼顧考慮了讀寫分離

緩存

緩存可以發(fā)生在這些層次：

MySQL內(nèi)部：在系統(tǒng)調(diào)優(yōu)參數(shù)介紹了相關設置

數(shù)據(jù)訪問層：比如MyBatis針對SQL語句做緩存，而Hibernate可以精確到單個記錄誓斥，這里緩存的對象主要是持久化對象Persistence Object

應用服務層：這里可以通過編程手段對緩存做到更精準的控制和更多的實現(xiàn)策略只洒，這里緩存的對象是數(shù)據(jù)傳輸對象Data Transfer Object

Web層：針對web頁面做緩存

瀏覽器客戶端：用戶端的緩存

可以根據(jù)實際情況在一個層次或多個層次結(jié)合加入緩存。這里重點介紹下服務層的緩存實現(xiàn)岖食，目前主要有兩種方式：

直寫式（Write Through）：在數(shù)據(jù)寫入數(shù)據(jù)庫后红碑，同時更新緩存舞吭，維持數(shù)據(jù)庫與緩存的一致性泡垃。這也是當前大多數(shù)應用緩存框架如Spring Cache的工作方式。這種實現(xiàn)非常簡單羡鸥，同步好蔑穴，但效率一般。

回寫式（Write Back）：當有數(shù)據(jù)要寫入數(shù)據(jù)庫時惧浴，只會更新緩存存和，然后異步批量的將緩存數(shù)據(jù)同步到數(shù)據(jù)庫上。這種實現(xiàn)比較復雜衷旅，需要較多的應用邏輯捐腿，同時可能會產(chǎn)生數(shù)據(jù)庫與緩存的不同步，但效率非常高柿顶。

表分區(qū)

MySQL在5.1版引入的分區(qū)是一種簡單的水平拆分茄袖，用戶需要在建表的時候加上分區(qū)參數(shù)，對應用是透明的無需修改代碼

對用戶來說嘁锯，分區(qū)表是一個獨立的邏輯表宪祥，但是底層由多個物理子表組成聂薪，實現(xiàn)分區(qū)的代碼實際上是通過對一組底層表的對象封裝，但對SQL層來說是一個完全封裝底層的黑盒子蝗羊。MySQL實現(xiàn)分區(qū)的方式也意味著索引也是按照分區(qū)的子表定義藏澳，沒有全局索引

用戶的SQL語句是需要針對分區(qū)表做優(yōu)化，SQL條件中要帶上分區(qū)條件的列耀找，從而使查詢定位到少量的分區(qū)上翔悠，否則就會掃描全部分區(qū)，可以通過EXPLAIN PARTITIONS來查看某條SQL語句會落在那些分區(qū)上野芒，從而進行SQL優(yōu)化凉驻，如下圖5條記錄落在兩個分區(qū)上：

mysql> explain partitions select count(1) from user_partition where id in (1,2,3,4,5);
+----+-------------+----------------+------------+-------+---------------+---------+---------+------+------+--------------------------+
| id | select_type | table          | partitions | type  | possible_keys | key     | key_len | ref  | rows | Extra                    |
+----+-------------+----------------+------------+-------+---------------+---------+---------+------+------+--------------------------+
|  1 | SIMPLE      | user_partition | p1,p4      | range | PRIMARY       | PRIMARY | 8       | NULL |    5 | Using where; Using index |
+----+-------------+----------------+------------+-------+---------------+---------+---------+------+------+--------------------------+
1 row in set (0.00 sec)

分區(qū)的好處是：

  • 可以讓單表存儲更多的數(shù)據(jù)

  • 分區(qū)表的數(shù)據(jù)更容易維護，可以通過清楚整個分區(qū)批量刪除大量數(shù)據(jù)复罐，也可以增加新的分區(qū)來支持新插入的數(shù)據(jù)涝登。另外，還可以對一個獨立分區(qū)進行優(yōu)化效诅、檢查胀滚、修復等操作

  • 部分查詢能夠從查詢條件確定只落在少數(shù)分區(qū)上，速度會很快

  • 分區(qū)表的數(shù)據(jù)還可以分布在不同的物理設備上乱投，從而搞笑利用多個硬件設備

  • 可以使用分區(qū)表賴避免某些特殊瓶頸咽笼，例如InnoDB單個索引的互斥訪問、ext3文件系統(tǒng)的inode鎖競爭

  • 可以備份和恢復單個分區(qū)

分區(qū)的限制和缺點：

  • 一個表最多只能有1024個分區(qū)

  • 如果分區(qū)字段中有主鍵或者唯一索引的列戚炫，那么所有主鍵列和唯一索引列都必須包含進來

  • 分區(qū)表無法使用外鍵約束

  • NULL值會使分區(qū)過濾無效

  • 所有分區(qū)必須使用相同的存儲引擎

分區(qū)的類型：

  • RANGE分區(qū)：基于屬于一個給定連續(xù)區(qū)間的列值口叙，把多行分配給分區(qū)

  • LIST分區(qū)：類似于按RANGE分區(qū)迎变，區(qū)別在于LIST分區(qū)是基于列值匹配一個離散值集合中的某個值來進行選擇

  • HASH分區(qū)：基于用戶定義的表達式的返回值來進行選擇的分區(qū)，該表達式使用將要插入到表中的這些行的列值進行計算。這個函數(shù)可以包含MySQL中有效的本讥、產(chǎn)生非負整數(shù)值的任何表達式

  • KEY分區(qū)：類似于按HASH分區(qū)怕膛，區(qū)別在于KEY分區(qū)只支持計算一列或多列猿推，且MySQL服務器提供其自身的哈希函數(shù)秘症。必須有一列或多列包含整數(shù)值

分區(qū)適合的場景有：

  • 最適合的場景數(shù)據(jù)的時間序列性比較強，則可以按時間來分區(qū)蔑赘，如下所示：

CREATE TABLE members (
    firstname VARCHAR(25) NOT NULL,
    lastname VARCHAR(25) NOT NULL,
    username VARCHAR(16) NOT NULL,
    email VARCHAR(35),
    joined DATE NOT NULL
)
PARTITION BY RANGE( YEAR(joined) ) (
    PARTITION p0 VALUES LESS THAN (1960),
    PARTITION p1 VALUES LESS THAN (1970),
    PARTITION p2 VALUES LESS THAN (1980),
    PARTITION p3 VALUES LESS THAN (1990),
    PARTITION p4 VALUES LESS THAN MAXVALUE
);

查詢時加上時間范圍條件效率會非常高狸驳，同時對于不需要的歷史數(shù)據(jù)能很容的批量刪除。

  • 如果數(shù)據(jù)有明顯的熱點缩赛，而且除了這部分數(shù)據(jù)耙箍，其他數(shù)據(jù)很少被訪問到，那么可以將熱點數(shù)據(jù)單獨放在一個分區(qū)酥馍，讓這個分區(qū)的數(shù)據(jù)能夠有機會都緩存在內(nèi)存中辩昆，查詢時只訪問一個很小的分區(qū)表，能夠有效使用索引和緩存

另外MySQL有一種早期的簡單的分區(qū)實現(xiàn) - 合并表（merge table）物喷，限制較多且缺乏優(yōu)化卤材，不建議使用遮斥，應該用新的分區(qū)機制來替代

垂直拆分

垂直分庫是根據(jù)數(shù)據(jù)庫里面的數(shù)據(jù)表的相關性進行拆分，比如：一個數(shù)據(jù)庫里面既存在用戶數(shù)據(jù)扇丛，又存在訂單數(shù)據(jù)术吗，那么垂直拆分可以把用戶數(shù)據(jù)放到用戶庫、把訂單數(shù)據(jù)放到訂單庫帆精。垂直分表是對數(shù)據(jù)表進行垂直拆分的一種方式较屿，常見的是把一個多字段的大表按常用字段和非常用字段進行拆分，每個表里面的數(shù)據(jù)記錄數(shù)一般情況下是相同的卓练，只是字段不一樣隘蝎，使用主鍵關聯(lián)

比如原始的用戶表是：

垂直拆分后是：

垂直拆分的優(yōu)點是：

  • 可以使得行數(shù)據(jù)變小，一個數(shù)據(jù)塊(Block)就能存放更多的數(shù)據(jù)襟企，在查詢時就會減少I/O次數(shù)(每次查詢時讀取的Block 就少)

  • 可以達到最大化利用Cache的目的嘱么，具體在垂直拆分的時候可以將不常變的字段放一起，將經(jīng)常改變的放一起

  • 數(shù)據(jù)維護簡單

缺點是：

  • 主鍵出現(xiàn)冗余顽悼，需要管理冗余列

  • 會引起表連接JOIN操作（增加CPU開銷）可以通過在業(yè)務服務器上進行join來減少數(shù)據(jù)庫壓力

  • 依然存在單表數(shù)據(jù)量過大的問題（需要水平拆分）

  • 事務處理復雜

水平拆分

概述
水平拆分是通過某種策略將數(shù)據(jù)分片來存儲曼振，分庫內(nèi)分表和分庫兩部分，每片數(shù)據(jù)會分散到不同的MySQL表或庫蔚龙，達到分布式的效果冰评，能夠支持非常大的數(shù)據(jù)量。前面的表分區(qū)本質(zhì)上也是一種特殊的庫內(nèi)分表

庫內(nèi)分表木羹，僅僅是單純的解決了單一表數(shù)據(jù)過大的問題甲雅，由于沒有把表的數(shù)據(jù)分布到不同的機器上，因此對于減輕MySQL服務器的壓力來說坑填，并沒有太大的作用抛人，大家還是競爭同一個物理機上的IO、CPU穷遂、網(wǎng)絡函匕，這個就要通過分庫來解決

前面垂直拆分的用戶表如果進行水平拆分，結(jié)果是：

image.png

實際情況中往往會是垂直拆分和水平拆分的結(jié)合蚪黑，即將Users_A_M和Users_N_Z再拆成Users和UserExtras，這樣一共四張表

水平拆分的優(yōu)點是:

  • 不存在單庫大數(shù)據(jù)和高并發(fā)的性能瓶頸

  • 應用端改造較少

  • 提高了系統(tǒng)的穩(wěn)定性和負載能力

缺點是：

  • 分片事務一致性難以解決

  • 跨節(jié)點Join性能差中剩，邏輯復雜

  • 數(shù)據(jù)多次擴展難度跟維護量極大

參考文獻

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末忌穿，一起剝皮案震驚了整個濱河市，隨后出現(xiàn)的幾起案子结啼，更是在濱河造成了極大的恐慌掠剑，老刑警劉巖，帶你破解...
    沈念sama閱讀 217,826評論 6贊 506
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件郊愧，死亡現(xiàn)場離奇詭異朴译，居然都是意外死亡井佑，警方通過查閱死者的電腦和手機，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,968評論 3贊 395
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門眠寿，熙熙樓的掌柜王于貴愁眉苦臉地迎上來躬翁，“玉大人，你說我怎么就攤上這事盯拱『蟹ⅲ” “怎么了？”我有些...
    開封第一講書人閱讀 164,234評論 0贊 354
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵狡逢，是天一觀的道長宁舰。 經(jīng)常有香客問我，道長奢浑，這世上最難降的妖魔是什么蛮艰？ 我笑而不...
    開封第一講書人閱讀 58,562評論 1贊 293
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任，我火速辦了婚禮雀彼，結(jié)果婚禮上印荔，老公的妹妹穿的比我還像新娘。我一直安慰自己详羡，他們只是感情好仍律，可當我...
    茶點故事閱讀 67,611評論 6贊 392
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布。 她就那樣靜靜地躺著实柠，像睡著了一般水泉。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上窒盐，一...
    開封第一講書人閱讀 51,482評論 1贊 302
  • 城市分裂傳說
    那天草则，我揣著相機與錄音，去河邊找鬼蟹漓。 笑死炕横，一個胖子當著我的面吹牛，可吹牛的內(nèi)容都是我干的葡粒。 我是一名探鬼主播份殿，決...
    沈念sama閱讀 40,271評論 3贊 418
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼嗽交！你這毒婦竟也來了卿嘲？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 39,166評論 0贊 276
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤夫壁，失蹤者是張志新（化名）和其女友劉穎拾枣，沒想到半個月后，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
    沈念sama閱讀 45,608評論 1贊 314
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡梅肤，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,814評論 3贊 336
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年司蔬，在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片姨蝴。...
    茶點故事閱讀 39,926評論 1贊 348
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡俊啼，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出似扔，到底是詐尸還是另有隱情吨些，我是刑警寧澤，帶...
    沈念sama閱讀 35,644評論 5贊 346
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布炒辉，位于F島的核電站豪墅，受9級特大地震影響，放射性物質(zhì)發(fā)生泄漏黔寇。R本人自食惡果不足惜偶器，卻給世界環(huán)境...
    茶點故事閱讀 41,249評論 3贊 329
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望缝裤。 院中可真熱鬧屏轰，春花似錦、人聲如沸憋飞。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,866評論 0贊 22
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽榛做。三九已至唁盏，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間检眯，已是汗流浹背厘擂。 一陣腳步聲響...
    開封第一講書人閱讀 32,991評論 1贊 269
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留锰瘸，地道東北人刽严。 一個月前我還...
    沈念sama閱讀 48,063評論 3贊 370
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像避凝，于是被迫代替她去往敵國和親舞萄。 傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當晚...
    茶點故事閱讀 44,871評論 2贊 354

推薦閱讀更多精彩內(nèi)容

  • 當MySQL單表記錄數(shù)過大時恕曲，增刪改查性能都會急劇下降鹏氧，可以參考以下步驟來優(yōu)化：單表優(yōu)化除非單表數(shù)據(jù)未來會一直不斷...
    扎Zn了老Fe閱讀 882評論 0贊 6
  • 摘要： 1.限定數(shù)據(jù)的范圍：查詢訂單歷史，控制一個月范圍实蓬。茸俭； 2.讀/寫分離：主庫寫吊履，從庫讀； 緩存：使用MySQ...
    hedgehog1112閱讀 1,833評論 0贊 30
  • 原文版權(quán) 當MySQL單表記錄數(shù)過大時调鬓，增刪改查性能都會急劇下降艇炎，可以參考以下步驟來優(yōu)化： 單表優(yōu)化 除非單表數(shù)據(jù)...
    若與閱讀 6,439評論 9贊 354
  • 李安三部曲： 《飲食男女》讓人震感意外的黃昏戀，打破世俗的牢籠腾窝，敢于追求自己的愛情缀踪，我們只能尊重，很前衛(wèi)的思想虹脯。一...
    奮飛的蝸牛ing閱讀 877評論 0贊 1
  • 歷城二中 倦夢還 我今天看到了一篇回憶歷城二中的文章 忽然間好多回憶就涌上來了啊 昨天發(fā)說說 初中很好的朋友評論說...
    倦夢還w閱讀 313評論 0贊 0