MySQL分表优化_MySQL
bitsCN.com
我们的项目中有好多不等于的情况。今天写这篇文章简单的分析一下怎么个优化法。
这里的分表逻辑是根据t_group表的user_name组的个数来分的。
因为这种情况单独user_name字段上的索引就属于烂索引。起不了啥名明显的效果。
1、试验PROCEDURE.
DELIMITER $$
Drop PROCEDURE `t_girl`.`sp_split_table`$$
Create PROCEDURE `t_girl`.`sp_split_table`()
BEGIN
declare done int default 0;
declare v_user_name varchar(20) default '';
declare v_table_name varchar(64) default '';
-- Get all users' name.
declare cur1 cursor for select user_name from t_group group by user_name;
-- Deal with error or warnings.
declare continue handler for 1329 set done = 1;
-- Open cursor.
open cur1;
while done 1
do
fetch cur1 into v_user_name;
if not done then
-- Get table name.
set v_table_name = concat('t_group_',v_user_name);
-- Create new extra table.
set @stmt = concat('create table ',v_table_name,' like t_group');
prepare s1 from @stmt;
execute s1;
drop prepare s1;
-- Load data into it.
set @stmt = concat('insert into ',v_table_name,' select * from t_group where user_name = ''',v_user_name,'''');
prepare s1 from @stmt;
execute s1;
drop prepare s1;
end if;
end while;
-- Close cursor.
close cur1;
-- Free variable from memory.
set @stmt = NULL;
END$$
DELIMITER ;
2、试验表。
我们用一个有一千万条记录的表来做测试。
mysql> select count(*) from t_group;
+----------+
| count(*) |
+----------+
| 10388608 |
+----------+
1 row in set (0.00 sec)
表结构。
mysql> desc t_group;
+-------------+------------------+------+-----+-------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+------------------+------+-----+-------------------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| money | decimal(10,2) | NO | | | |
| user_name | varchar(20) | NO | MUL | | |
| create_time | timestamp | NO | | CURRENT_TIMESTAMP | |
+-------------+------------------+------+-----+-------------------+----------------+
4 rows in set (0.00 sec)
索引情况。
mysql> show index from t_group;
+---------+------------+------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
|Table | Non_unique | Key_name | Seq_in_index | Column_name |Collation | Cardinality | Sub_part | Packed | Null | Index_type |Comment |
+---------+------------+------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
|t_group | 0 | PRIMARY | 1 | id |A | 10388608 | NULL | NULL | | BTREE | |
| t_group | 1 | idx_user_name | 1 | user_name | A | 8 | NULL | NULL | |BTREE | |
| t_group | 1 | idx_combination1| 1 | user_name | A | 8 | NULL |NULL | | BTREE | |
| t_group | 1 |idx_combination1 | 2 | money | A | 3776| NULL | NULL | | BTREE | |
+---------+------------+------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
4 rows in set (0.00 sec)
PS:
idx_combination1 这个索引是必须的,因为要对user_name来GROUP BY。此时属于松散索引扫描!当然完了后你可以干掉她。
idx_user_name 这个索引是为了加快单独执行constant这种类型的查询。
我们要根据用户名来分表
mysql> select user_name from t_group where 1 group by user_name;
+-----------+
| user_name |
+-----------+
| david |
| leo |
| livia |
| lucy |
| sarah |
| simon |
| sony |
| sunny |
+-----------+
8 rows in set (0.00 sec)
所以结果表应该是这样的。
mysql> show tables like 't_group_%';
+------------------------------+
| Tables_in_t_girl (t_group_%) |
+------------------------------+
| t_group_david |
| t_group_leo |
| t_group_livia |
| t_group_lucy |
| t_group_sarah |
| t_group_simon |
| t_group_sony |
| t_group_sunny |
+------------------------------+
8 rows in set (0.00 sec)
3、对比结果。
mysql> select count(*) from t_group where user_name = 'david';
+----------+
| count(*) |
+----------+
| 1298576 |
+----------+
1 row in set (1.71 sec)
执行了将近2秒。
mysql> select count(*) from t_group_david;
+----------+
| count(*) |
+----------+
| 1298576 |
+----------+
1 row in set (0.00 sec)
几乎是瞬间的。
mysql> select count(*) from t_group where user_name 'david';
+----------+
| count(*) |
+----------+
| 9090032 |
+----------+
1 row in set (9.26 sec)
执行了将近10秒,可以想象,这个是实际的项目中是不能忍受的。
mysql> select (select count(*) from t_group) - (select count(*) from t_group_david) as total;
+---------+
| total |
+---------+
| 9090032 |
+---------+
1 row in set (0.00 sec)
几乎是瞬间的。
我们来看看聚集函数。
对于原表的操作。
mysql> select min(money),max(money) from t_group where user_name = 'david';
+------------+------------+
| min(money) | max(money) |
+------------+------------+
| -6.41 | 500.59 |
+------------+------------+
1 row in set (0.00 sec)
最小,最大值都是FULL INDEX SCAN。所以是瞬间的。
mysql> select sum(money),avg(money) from t_group where user_name = 'david';
+--------------+------------+
| sum(money) | avg(money) |
+--------------+------------+
| 319992383.84 | 246.417910 |
+--------------+------------+
1 row in set (2.15 sec)
其他聚集函数的结果就不是FULL INDEX SCAN了。耗时2.15秒。
对于小表的操作。
mysql> select min(money),max(money) from t_group_david;
+------------+------------+
| min(money) | max(money) |
+------------+------------+
| -6.41 | 500.59 |
+------------+------------+
1 row in set (1.50 sec)
最大最小值完全是FULL TABLE SCAN,耗时1.50秒,不划算。以此看来。
mysql> select sum(money),avg(money) from t_group_david;
+--------------+------------+
| sum(money) | avg(money) |
+--------------+------------+
| 319992383.84 | 246.417910 |
+--------------+------------+
1 row in set (1.68 sec)
取得这两个结果也是花了快2秒,快了一点。
我们来看看这个小表的结构。
mysql> desc t_group_david;
+-------------+------------------+------+-----+-------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+------------------+------+-----+-------------------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| money | decimal(10,2) | NO | | | |
| user_name | varchar(20) | NO | MUL | | |
| create_time | timestamp | NO | | CURRENT_TIMESTAMP | |
+-------------+------------------+------+-----+-------------------+----------------+
4 rows in set (0.00 sec)
明显的user_name属性是多余的。那么就干掉它。
mysql> alter table t_group_david drop user_name;
Query OK, 1298576 rows affected (7.58 sec)
Records: 1298576 Duplicates: 0 Warnings: 0
现在来重新对小表运行查询
mysql> select min(money),max(money) from t_group_david;
+------------+------------+
| min(money) | max(money) |
+------------+------------+
| -6.41 | 500.59 |
+------------+------------+
1 row in set (0.00 sec)
此时是瞬间的。
mysql> select sum(money),avg(money) from t_group_david;
+--------------+------------+
| sum(money) | avg(money) |
+--------------+------------+
| 319992383.84 | 246.417910 |
+--------------+------------+
1 row in set (0.94 sec)
这次算是控制在一秒以内了。
mysql> Aborted
小总结一下:分出的小表的属性尽量越少越好。大胆的去干吧
第零空间版权所有
bitsCN.com

熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

Video Face Swap
使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

熱工具

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

禪工作室 13.0.1
強大的PHP整合開發環境

Dreamweaver CS6
視覺化網頁開發工具

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)

一、今日頭條發布文章怎麼有收益?今日頭條發布文章獲得更多收益方法! 1.開通基礎權益:原創文章選擇投放廣告可獲得收益,影片必須原創橫屏才會有收益。 2.開通百粉權益:粉絲量達百粉以上,微頭條、原創問答創作及問答均可獲得收益。 3.堅持原創作品:原創作品包含文章、微標題及問題等,要求300字以上。注意違規抄襲作品作為原創發布,會被扣信用分,即使有收益也會被扣除。 4.垂直度:做專業領域一類的文章,不能隨意跨領域寫文章,會得不到合適的推薦,達不到作品的專和精,難以吸引粉絲讀者。 5.活躍度:活躍度高,

我們在收到新電腦後要怎麼設定優化效能,使用者可以直接的開啟隱私和安全性,然後點擊常規(廣告ID,本地內容,應用程式啟動,設定建議,生產力工具或直接的開啟本地群組策略編輯器來進行操作就可以了。下面就讓本來為用戶們來仔細的介紹一下Win11新電腦收到後如何優化設置提升性能的方法吧。Win11新電腦收到後如何優化設置提升性能的方法方法一:1、按【Win+i】組合鍵,開啟設置,然後左側點選【隱私與安全性】,右側點選Windows權限下的【常規(廣告ID,本地內容,應用程式啟動,設定建議,生產力工具)】。方法二

時間複雜度衡量演算法執行時間與輸入規模的關係。降低C++程式時間複雜度的技巧包括:選擇合適的容器(如vector、list)以最佳化資料儲存和管理。利用高效演算法(如快速排序)以減少計算時間。消除多重運算以減少重複計算。利用條件分支以避免不必要的計算。透過使用更快的演算法(如二分搜尋)來優化線性搜尋。

解碼Laravel效能瓶頸:優化技巧全面揭秘! Laravel作為一個受歡迎的PHP框架,為開發者提供了豐富的功能和便利的開發體驗。然而,隨著專案規模增加和訪問量增加,我們可能會面臨效能瓶頸的挑戰。本文將深入探討Laravel效能最佳化的技巧,幫助開發者發現並解決潛在的效能問題。一、資料庫查詢優化使用Eloquent延遲載入在使用Eloquent查詢資料庫時,避免

Laravel是一款廣受歡迎的PHP開發框架,但有時候被人詬病的就是其速度慢如蝸牛。究竟是什麼原因導致了Laravel的速度不盡人意呢?本文將從多個面向深入解讀Laravel速度慢如蝸牛的原因,並結合具體的程式碼範例,幫助讀者更深入地了解此問題。 1.ORM查詢效能問題在Laravel中,ORM(物件關係映射)是一個非常強大的功能,可以讓

Golang的垃圾回收(GC)一直是開發者關注的熱門話題。 Golang作為一門快速的程式語言,其自帶的垃圾回收器能夠很好地管理內存,但隨著程式規模的增大,有時會出現一些效能問題。本文將探討Golang的GC最佳化策略,並提供一些具體的程式碼範例。 Golang中的垃圾回收Golang的垃圾回收器採用的是基於並發標記-清除(concurrentmark-s

Laravel效能瓶頸揭秘:優化方案大揭秘!隨著網路技術的發展,網站和應用程式的效能優化變得愈發重要。作為一款流行的PHP框架,Laravel在開發過程中可能會面臨效能瓶頸。本文將探討Laravel應用程式可能遇到的效能問題,並提供一些最佳化方案和具體的程式碼範例,讓開發者能夠更好地解決這些問題。一、資料庫查詢最佳化資料庫查詢是Web應用中常見的效能瓶頸之一。在

1.在桌面上按組合鍵(win鍵+R)開啟運行窗口,接著輸入【regedit】,回車確認。 2.開啟登錄編輯程式後,我們依序點選展開【HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorer】,然後看目錄裡有沒有Serialize項,如果沒有我們可以點選右鍵Explorer,新建項,並將其命名為Serialize。 3.接著點選Serialize,然後在右邊窗格空白處點選滑鼠右鍵,新建一個DWORD(32)位元值,並將其命名為Star
