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 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









1. 今すぐ Toutiao の記事を公開してどうやってお金を稼ぐことができますか?今すぐ Toutiao で記事を公開して収入を増やす方法! 1. 基本的な権利と利益の有効化: オリジナルの記事は広告によって利益を得ることができますが、利益を得るにはビデオが横画面モードでオリジナルである必要があります。 2. ファン100人の権利を有効化:ファン数が100人以上に達すると、マイクロヘッドライン、オリジナルQ&A作成、Q&Aから利益を得ることができます。 3. オリジナル作品にこだわる: オリジナル作品には記事、小見出し、質問などが含まれ、300 ワード以上であることが求められます。違法に盗用された作品をオリジナル作品として出版した場合、クレジットポイントが減点され、利益も差し引かれますのでご注意ください。 4. 垂直性:専門分野の記事を書く場合、分野を超えて自由に記事を書くことができず、適切な推薦が得られず、専門性や洗練度が得られず、ファンもつきにくいそして読者たち。 5. 活動: 高活動、

新しいコンピュータを受け取った後、パフォーマンスをセットアップして最適化するにはどうすればよいですか? ユーザーは、[プライバシーとセキュリティ] を直接開き、[全般] (広告 ID、ローカル コンテンツ、アプリケーションの起動、推奨事項の設定、生産性向上ツール) をクリックするか、ローカル グループ ポリシーを直接開くことができます。新しい Win11 パソコンを受け取った後に、設定を最適化し、パフォーマンスを向上させる方法について詳しくご紹介します。 新しい Win11 パソコンを受け取った後に、設定を最適化し、パフォーマンスを向上させる方法について詳しくご紹介します。 1 つ: 1. [Win+i] ボタンを押します。 ] キーの組み合わせを押して設定を開き、左側の [プライバシーとセキュリティ] をクリックし、[右側のツールの Windows アクセス許可の下の一般 (広告 ID、ローカル コンテンツ、アプリの起動、設定の提案、生産性)] をクリックします。方法 2

Laravel は人気のある PHP 開発フレームワークですが、カタツムリのように遅いと批判されることがあります。 Laravel の速度が満足できない原因は一体何でしょうか?この記事では、Laravel がカタツムリのように遅い理由をさまざまな側面から詳細に説明し、読者がこの問題をより深く理解できるように、具体的なコード例と組み合わせて説明します。 1. ORM クエリのパフォーマンスの問題 Laravel では、ORM (オブジェクト リレーショナル マッピング) は非常に強力な機能です。

Golang のガベージ コレクション (GC) は、開発者の間で常に話題になっています。高速プログラミング言語として、Golang の組み込みガベージ コレクターはメモリを適切に管理できますが、プログラムのサイズが大きくなるにつれて、パフォーマンスの問題が発生することがあります。この記事では、Golang の GC 最適化戦略を検討し、いくつかの具体的なコード例を示します。 Golang のガベージ コレクション Golang のガベージ コレクターは同時マークスイープ (concurrentmark-s) に基づいています。

時間計算量は、入力のサイズに対するアルゴリズムの実行時間を測定します。 C++ プログラムの時間の複雑さを軽減するためのヒントには、適切なコンテナー (ベクター、リストなど) を選択して、データのストレージと管理を最適化することが含まれます。クイックソートなどの効率的なアルゴリズムを利用して計算時間を短縮します。複数の操作を排除して二重カウントを削減します。条件分岐を使用して、不必要な計算を回避します。二分探索などのより高速なアルゴリズムを使用して線形探索を最適化します。

Laravelのパフォーマンスボトルネックを解読:最適化テクニックを完全公開! Laravel は人気のある PHP フレームワークとして、開発者に豊富な機能と便利な開発エクスペリエンスを提供します。ただし、プロジェクトのサイズが大きくなり、訪問数が増加すると、パフォーマンスのボトルネックという課題に直面する可能性があります。この記事では、開発者が潜在的なパフォーマンスの問題を発見して解決できるように、Laravel のパフォーマンス最適化テクニックについて詳しく説明します。 1. Eloquent の遅延読み込みを使用したデータベース クエリの最適化 Eloquent を使用してデータベースにクエリを実行する場合は、次のことを避けてください。

Laravel パフォーマンスのボトルネックが明らかに: 最適化ソリューションが明らかに!インターネット技術の発展に伴い、Web サイトやアプリケーションのパフォーマンスの最適化がますます重要になってきています。人気の PHP フレームワークである Laravel は、開発プロセス中にパフォーマンスのボトルネックに直面する可能性があります。この記事では、Laravel アプリケーションが遭遇する可能性のあるパフォーマンスの問題を調査し、開発者がこれらの問題をより適切に解決できるように、いくつかの最適化ソリューションと具体的なコード例を提供します。 1. データベース クエリの最適化 データベース クエリは、Web アプリケーションにおける一般的なパフォーマンスのボトルネックの 1 つです。存在する

1. デスクトップでキーの組み合わせ (win キー + R) を押してファイル名を指定して実行ウィンドウを開き、[regedit] と入力して Enter キーを押して確定します。 2. レジストリ エディターを開いた後、[HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorer] をクリックして展開し、ディレクトリに Serialize 項目があるかどうかを確認します。ない場合は、エクスプローラーを右クリックして新しい項目を作成し、Serialize という名前を付けます。 3. 次に、「シリアル化」をクリックし、右側のペインの空白スペースを右クリックして、新しい DWORD (32) ビット値を作成し、「Star」という名前を付けます。
