mysql表大怎么優化 數據庫表太大怎么優化

MySQL 對于大表，要怎么優化

至少有3個方法

競秀網站建設公司創新互聯公司,競秀網站設計制作，有大型網站制作公司豐富經驗。已為競秀超過千家提供企業網站建設服務。企業網站搭建\成都外貿網站建設公司要多少錢，請找那個售后服務好的競秀做網站的公司定做！

1、大表拆成若干個表，缺點：程序方面需要修改。

2、大表做分區表，缺點：這個分區表的字段沒有選擇好，會影響性能。

3、大表定期，手動把不用的老數據導出到另外一張表，保持大表數據不會過多。

mysql數據庫表太大查詢慢優化的幾種方法

優化方案：

主從同步+讀寫分離：

這個表在有設備條件的情況下，讀寫分離，這樣能減少很多壓力，而且數據穩定性也能提高

縱向分表：

根據原則，每個表最多不要超過5個索引，縱向拆分字段，將部分字段拆到一個新表

通常我們按以下原則進行垂直拆分:（先區分這個表中的冷熱數據字段）

把不常用的字段單獨放在一張表;

把text，blob等大字段拆分出來放在附表中;

經常組合查詢的列放在一張表中;

缺點是：很多邏輯需要重寫，帶來很大的工作量。

利用表分區：

這個是推薦的一個解決方案，不會帶來重寫邏輯等，可以根據時間來進行表分區，相當于在同一個磁盤上，表的數據存在不同的文件夾內，能夠極大的提高查詢速度。

橫向分表：

1000W條數據不少的，會帶來一些運維壓力，備份的時候，單表備份所需時間會很長，所以可以根據服務器硬件條件進行水平分表，每個表有多少數據為準。

Mysql某個表有近千萬數據，CRUD比較慢，如何優化？

數據千萬級別之多，占用的存儲空間也比較大，可想而知它不會存儲在一塊連續的物理空間上，而是鏈式存儲在多個碎片的物理空間上。可能對于長字符串的比較，就用更多的時間查找與比較，這就導致用更多的時間。

可以做表拆分，減少單表字段數量，優化表結構。

在保證主鍵有效的情況下，檢查主鍵索引的字段順序，使得查詢語句中條件的字段順序和主鍵索引的字段順序保持一致。

主要兩種拆分 垂直拆分，水平拆分。

垂直分表

也就是“大表拆小表”，基于列字段進行的。一般是表中的字段較多，將不常用的， 數據較大，長度較長（比如text類型字段）的拆分到“擴展表“。 一般是針對 那種 幾百列的大表，也避免查詢時，數據量太大造成的“跨頁”問題。

垂直分庫針對的是一個系統中的不同業務進行拆分，比如用戶User一個庫，商品Product一個庫，訂單Order一個庫。 切分后，要放在多個服務器上，而不是一個服務器上。為什么？ 我們想象一下，一個購物網站對外提供服務，會有用戶，商品，訂單等的CRUD。沒拆分之前， 全部都是落到單一的庫上的，這會讓數據庫的單庫處理能力成為瓶頸。按垂直分庫后，如果還是放在一個數據庫服務器上， 隨著用戶量增大，這會讓單個數據庫的處理能力成為瓶頸，還有單個服務器的磁盤空間，內存，tps等非常吃緊。 所以我們要拆分到多個服務器上，這樣上面的問題都解決了，以后也不會面對單機資源問題。

數據庫業務層面的拆分，和服務的“治理”，“降級”機制類似，也能對不同業務的數據分別的進行管理，維護，監控，擴展等。 數據庫往往最容易成為應用系統的瓶頸，而數據庫本身屬于“有狀態”的，相對于Web和應用服務器來講，是比較難實現“橫向擴展”的。 數據庫的連接資源比較寶貴且單機處理能力也有限，在高并發場景下，垂直分庫一定程度上能夠突破IO、連接數及單機硬件資源的瓶頸。

水平分表

針對數據量巨大的單張表（比如訂單表），按照某種規則（RANGE,HASH取模等），切分到多張表里面去。 但是這些表還是在同一個庫中，所以庫級別的數據庫操作還是有IO瓶頸。不建議采用。

水平分庫分表

將單張表的數據切分到多個服務器上去，每個服務器具有相應的庫與表，只是表中數據集合不同。 水平分庫分表能夠有效的緩解單機和單庫的性能瓶頸和壓力，突破IO、連接數、硬件資源等的瓶頸。

水平分庫分表切分規則

1. RANGE

從0到10000一個表，10001到20000一個表；

2. HASH取模

一個商場系統，一般都是將用戶，訂單作為主表，然后將和它們相關的作為附表，這樣不會造成跨庫事務之類的問題。 取用戶id，然后hash取模，分配到不同的數據庫上。

3. 地理區域

比如按照華東，華南，華北這樣來區分業務，七牛云應該就是如此。

4. 時間

按照時間切分，就是將6個月前，甚至一年前的數據切出去放到另外的一張表，因為隨著時間流逝，這些表的數據 被查詢的概率變小，所以沒必要和“熱數據”放在一起，這個也是“冷熱數據分離”。

分庫分表后面臨的問題

事務支持

分庫分表后，就成了分布式事務了。如果依賴數據庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價； 如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。

跨庫join

只要是進行切分，跨節點Join的問題是不可避免的。但是良好的設計和切分卻可以減少此類情況的發生。解決這一問題的普遍做法是分兩次查詢實現。在第一次查詢的結果集中找出關聯數據的id,根據這些id發起第二次請求得到關聯數據。

跨節點的count,order by,group by以及聚合函數問題

這些是一類問題，因為它們都需要基于全部數據集合進行計算。多數的代理都不會自動處理合并工作。解決方案：與解決跨節點join問題的類似，分別在各個節點上得到結果后在應用程序端進行合并。和join不同的是每個結點的查詢可以并行執行，因此很多時候它的速度要比單一大表快很多。但如果結果集很大，對應用程序內存的消耗是一個問題。

數據遷移，容量規劃，擴容等問題

來自淘寶綜合業務平臺團隊，它利用對2的倍數取余具有向前兼容的特性（如對4取余得1的數對2取余也是1）來分配數據，避免了行級別的數據遷移，但是依然需要進行表級別的遷移，同時對擴容規模和分表數量都有限制。總得來說，這些方案都不是十分的理想，多多少少都存在一些缺點，這也從一個側面反映出了Sharding擴容的難度。

ID問題

一旦數據庫被切分到多個物理結點上，我們將不能再依賴數據庫自身的主鍵生成機制。一方面，某個分區數據庫自生成的ID無法保證在全局上是唯一的；另一方面，應用程序在插入數據之前需要先獲得ID,以便進行SQL路由.

一些常見的主鍵生成策略

UUID

使用UUID作主鍵是最簡單的方案，但是缺點也是非常明顯的。由于UUID非常的長，除占用大量存儲空間外，最主要的問題是在索引上，在建立索引和基于索引進行查詢時都存在性能問題。

Twitter的分布式自增ID算法Snowflake

在分布式系統中，需要生成全局UID的場合還是比較多的，twitter的snowflake解決了這種需求，實現也還是很簡單的，除去配置信息，核心代碼就是毫秒級時間41位 機器ID 10位 毫秒內序列12位。

跨分片的排序分頁

一般來講，分頁時需要按照指定字段進行排序。當排序字段就是分片字段的時候，我們通過分片規則可以比較容易定位到指定的分片，而當排序字段非分片字段的時候，情況就會變得比較復雜了。為了最終結果的準確性，我們需要在不同的分片節點中將數據進行排序并返回，并將不同分片返回的結果集進行匯總和再次排序，最后再返回給用戶。

mysql對于大表（千萬級），要怎么優化

第一優化你的sql和索引；

第二加緩存，memcached,redis；

第三以上都做了后，還是慢，就做主從復制或主主復制，讀寫分離，可以在應用層做，效率高，也可以用三方工具，第三方工具推薦360的atlas,其它的要么效率不高，要么沒人維護；

第四如果以上都做了還是慢，不要想著去做切分，mysql自帶分區表，先試試這個，對你的應用是透明的，無需更改代碼,但是sql語句是需要針對分區表做優化的，sql條件中要帶上分區條件的列，從而使查詢定位到少量的分區上，否則就會掃描全部分區，另外分區表還有一些坑，在這里就不多說了；

第五如果以上都做了，那就先做垂直拆分，其實就是根據你模塊的耦合度，將一個大的系統分為多個小的系統，也就是分布式系統；

第六水平切分，針對數據量大的表，這一步最麻煩，最能考驗技術水平，要選擇一個合理的sharding key,為了有好的查詢效率，表結構也要改動，做一定的冗余，應用也要改，sql中盡量帶sharding key，將數據定位到限定的表上去查，而不是掃描全部的表；

Mysql多字段大表的幾種優化方法

一、優化表的數據類型

select * from tablename procedure analyse(16.265);

上面輸出一列信息，牟你數據表的字段提出優化建義，

二、通過拆分表提高數據訪問效率

拆分一是指針對表進行拆分，如果是針對myisam類型的表進行處理的話，可以有兩種拆分方法

1、是垂直拆分，把主要的與一些散放到一個表，然后把主要的和另外的列放在另一張表。

2、水平拆分方法，根據一列或多列的值把數據行放到兩個獨立的表中，水平拆分通常幾種情況。

表很大，拆分后可降低查詢時數據和索引的查詢速度，同時也降低了索引的層數，提高查詢的速度。

表中的數據本來就有獨立性，表中分別記錄各個地區的數據或不同時期的數據，特別是有些數據常用，廁國一些數據不常用的情況下，

需要把數據存放到多個不同的介質上。

三、逆規范化

四、使用中間表優化方法

對于數據庫教程大的表源碼天空

MySQL 對于千萬級的大表要怎么優化

MySQL 對于千萬級的大表的優化：

常用的優化sql----突出快字，使完成操作的時間最短

1、用索引提高效率：

2、選擇有效率的表名順序，及數據結構及字段；

3、使用DECODE函數可以避免重復掃描相同記錄或重復連接相同的表；

4、刪除重復記；

5、過內部函數提高SQL效率；

......

讀寫分離-----操作不在一個表里完成

1、主數據庫A，進行事務性增、改、刪操作（INSERT、UPDATE、DELETE）；

2、從數據庫B，進行SELECT查詢操作；

3、A復制到B，使數據保持一致性；

垂直劃分 ------數據不存儲在一個服務器里

按照功能劃分，把數據分別放到不同的數據庫和服務器。如博客功能的放到服務器A，儲存文件放到服務器B；

水平劃分------相同數據結構的數據不放在一張表里

把一個表的數據根據一定的規則劃分到不同的數據庫，兩個數據庫的表結構一樣。

數據歸檔處理-----時間優先原則存儲讀取

將數據庫中不經常使用的數據遷移至近線設備，將長期不使用的數據遷移至文件形式歸檔。這樣，隨著應用的需要，數據會在在線、近線和文件文檔之間移動，如當應用需要訪問很久以前的某些數據，它們的物理位置在近線設備，則會自動移動到在線設備。對用戶的應用而言，這些都是透明的，就像所有數據都存放在在線設備一樣，不會對數據庫應用產生任何影響。

分享文章：mysql表大怎么優化 數據庫表太大怎么優化
本文鏈接：http://m.kartarina.com/article44/hgjdee.html

成都網站建設公司_創新互聯，為您提供小程序開發、網站改版、App設計、關鍵詞優化、電子商務、響應式網站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯