MySQL 分表最佳化試驗程式碼
這裡的分表邏輯是根據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
小總結一下:分出的小表的屬性儘量越少越好。大膽的去幹吧。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/3034/viewspace-2803740/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MYSQL效能最佳化分享(分庫分表)MySql
- 得物面試:MySQL 深度分頁如何最佳化?面試MySql
- MySQL分頁查詢offset過大,Sql最佳化經驗MySql
- [Mysql]分庫分表MySql
- mysql分頁時offset過大的Sql最佳化經驗分享MySql
- MYSQL程式碼顯示測試測試MySql
- selenium最佳化後的測試程式碼
- Mysql資料庫大表最佳化方案和Mysql大表最佳化步驟MySql資料庫
- JavaScript 表單驗證程式碼例項JavaScript
- Oracle最佳化之單表分頁最佳化Oracle
- table表頭分組程式碼例項
- 3.1 MYSQL分庫分表實踐MySql
- Linux MySQL分庫分表之MycatLinuxMySql
- MySQL全面瓦解28:分庫分表MySql
- MySQL分庫分表的原則MySql
- MySql分表、分庫、分片和分割槽MySql
- 徹底搞清MySQL分庫分表(垂直分庫,垂直分表,水平分庫,水平分表)MySql
- mysql驅動表、被驅動表、大表小表及join最佳化MySql
- php7連線mysql測試程式碼PHPMySql
- XtraBackup不停機不鎖表做MySQL主從複製的試驗MySql
- MySQL 分庫分表方案,總結太全了。。MySql
- MYSQL壓縮表測試MySql
- MySQL 大表最佳化方案,收藏了細看!MySql
- SQL最佳化案例-單表分頁語句的最佳化(八)SQL
- 控制程式碼表篇——程式控制程式碼表
- MySQL 常用分庫分表方案,都在這裡了!MySql
- MySQL分表後原分割槽表處理方案MySql
- mysql~關於mysql分割槽表的測試MySql
- 程式碼最佳化記錄
- 基於MySql主從分離的程式碼層實現MySql
- 好程式設計師分享Java常見面試題Tomcat最佳化經驗程式設計師Java面試題Tomcat
- SpringBoot+MybatisPlus+Mysql+Sharding-JDBC分庫分表實踐Spring BootMyBatisMySqlJDBC
- sharding-jdbc分表場景下的分頁查詢最佳化JDBC
- MATLAB 檢驗資料正態分佈及程式碼實現Matlab
- MySQL資料庫之分庫分表方案MySql資料庫
- pt-archiver實現MySQL定期分表HiveMySql
- mysql count函式與分頁功能極限最佳化MySql函式
- ShardingSphere + Mysql,實現分庫分表、讀寫分離,並整合 SpringBootMySqlSpring Boot