[MySQL优化案例]系列 -- OPTIMIZE的威力
2024-05-14 10:47:46
作/译者：叶金荣（Email: 
），来源：http://imysql.cn，转载请注明作/译者和出处，并且不能用于商业用途，违者必究。
），来源：http://imysql.cn，转载请注明作/译者和出处，并且不能用于商业用途，违者必究。
1、先来看看多次删除插入操作后的表索引情况
mysql> SHOW INDEX FROM `tbl_name`; +----------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | +----------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ | tbl_name | 0 | PRIMARY | 1 | StepID | A | 1 | NULL | NULL | | BTREE | | | tbl_name | 1 | FlowID | 1 | FlowID | A | 1 | NULL | NULL | | BTREE | | | tbl_name | 1 | WagerCount | 1 | WagerCount | A | 1 | NULL | NULL | | BTREE | | | tbl_name | 1 | WagerID_3 | 1 | WagerID | A | 1 | NULL | NULL | | BTREE | | | tbl_name | 1 | WagerID_3 | 2 | StepType | A | 1 | NULL | NULL | | BTREE | | | tbl_name | 1 | WagerID_3 | 3 | ParamResult | A | 1 | 255 | NULL | | BTREE | | | tbl_name | 1 | StepType_2 | 1 | StepType | A | 1 | NULL | NULL | | BTREE | | | tbl_name | 1 | StepType_2 | 2 | ParamResult | A | 1 | 255 | NULL | | BTREE | | | tbl_name | 1 | WagerID_2 | 1 | WagerID | A | 1 | NULL | NULL | | BTREE | | | tbl_name | 1 | WagerID_2 | 2 | StepType | A | 1 | NULL | NULL | | BTREE | | | tbl_name | 1 | WagerID_2 | 3 | ParamResult | A | 1 | 255 | NULL | | BTREE | | +----------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ 11 rows in set (0.01 sec)
2、优化表
mysql> optimize table tbl_name; +---------------+----------+----------+----------+ | Table | Op | Msg_type | Msg_text | +---------------+----------+----------+----------+ | test.tbl_name | optimize | status | OK | +---------------+----------+----------+----------+ 1 row in set (40.60 sec)
3、再来看看优化后的效果
mysql> SHOW INDEX FROM `tbl_name`; +----------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | +----------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ | tbl_name | 0 | PRIMARY | 1 | StepID | A | 172462 | NULL | NULL | | BTREE | | | tbl_name | 1 | FlowID | 1 | FlowID | A | 86231 | NULL | NULL | | BTREE | | | tbl_name | 1 | WagerCount | 1 | WagerCount | A | 4311 | NULL | NULL | | BTREE | | | tbl_name | 1 | WagerID_3 | 1 | WagerID | A | 86231 | NULL | NULL | | BTREE | | | tbl_name | 1 | WagerID_3 | 2 | StepType | A | 172462 | NULL | NULL | | BTREE | | | tbl_name | 1 | WagerID_3 | 3 | ParamResult | A | 172462 | 255 | NULL | | BTREE | | | tbl_name | 1 | StepType_2 | 1 | StepType | A | 9 | NULL | NULL | | BTREE | | | tbl_name | 1 | StepType_2 | 2 | ParamResult | A | 86231 | 255 | NULL | | BTREE | | | tbl_name | 1 | WagerID_2 | 1 | WagerID | A | 86231 | NULL | NULL | | BTREE | | | tbl_name | 1 | WagerID_2 | 2 | StepType | A | 172462 | NULL | NULL | | BTREE | | | tbl_name | 1 | WagerID_2 | 3 | ParamResult | A | 172462 | 255 | NULL | | BTREE | | +----------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
最后，来看看手册中关于 OPTIMIZE 的描述：
OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ... 如果您已经删除了表的一大部分，或者如果您已经对含有可变长度行的表（含有VARCHAR, BLOB或TEXT列的表）进行了很多更改，则应使用 OPTIMIZE TABLE。被删除的记录被保持在链接清单中，后续的INSERT操作会重新使用旧的记录位置。您可以使用OPTIMIZE TABLE来重新 利用未使用的空间，并整理数据文件的碎片。 在多数的设置中，您根本不需要运行OPTIMIZE TABLE。即使您对可变长度的行进行了大量的更新，您也不需要经常运行，每周一次或每月一次 即可，只对特定的表运行。 OPTIMIZE TABLE只对MyISAM, BDB和InnoDB表起作用。 注意，在OPTIMIZE TABLE运行过程中，MySQL会锁定表。 本文出自 “MySQL中文网”博客 http://www.imysql.cn/
[MySQL优化案例]系列 -- OPTIMIZE的威力相关推荐
- mysql 优化 案例_[MySQL优化案例]系列 -- OPTIMIZE的威力
作/译者:叶金荣(Email: ),来源:http://imysql.cn,转载请注明作/译者和出处,并且不能用于商业用途,违者必究. 1.先来看看多次删除插入操作后的表索引情况 mysql> ...
- mysql表disable_[MySQL优化案例]系列 -- DISABLE/ENABLE KEYS的作用
[MySQL优化案例]系列 -- DISABLE/ENABLE KEYS的作用 作/译者:叶金荣 来源:http://imysql.cn 转载请注明作/译者和出处,并且不能用于商业用途,违者必究. 有 ...
- [MySQL优化案例]系列 — slave延迟很大优化方法
备注:插图来自网络搜索,如果觉得不当还请及时告知 :) 一般而言,slave相对master延迟较大,其根本原因就是slave上的复制线程没办法真正做到并发.简单说,在master上是并发模式(以In ...
- [MySQL优化案例]系列 — 典型性索引引发CPU负载飙升问题
收到一个mysql服务器负载告警,上去一看,load average都飙到280多了,用top一看,CPU跑到了336%,不过IO和内存的负载并不高,根据经验,应该又是一起索引引起的惨案了. 看下pr ...
- [MySQL优化案例]系列 -- 试用TCMalloc
作/译者:叶金荣(Email: ),来源:http://imysql.cn,转载请注明作/译者和出处,并且不能用于商业用途,违者必究. TCMalloc 是用于优化C++写的多线程应用,比glibc ...
- [MySQL优化案例]系列 -- 用TIMESTAMP类型取代INT和DATETIME
引言:在以前,我总是习惯用 INT UNSIGNED 来存储一个转换成Unix时间戳的时间值,认为这样做从索引,比较等角度来讲,都会比较高效.现在我们来对比下 TIMESTAMP 和 INT UNSI ...
- [MySQL优化案例]系列 -- DISABLE/ENABLE KEYS的作用
作/译者:叶金荣(Email: ),来源:http://imysql.cn,转载请注明作/译者和出处,并且不能用于商业用途,违者必究. 有一个表 tbl1 的结构如下: CREATE TABLE `t ...
- 【MySQL】故障分析 | MySQL 优化案例 - 字符集转换
1.概述 好文章转载:故障分析 | MySQL 优化案例 - 字符集转换 一.背景 开发联系我,说是开发库上有一张视图查询速度很慢,9000 条数据要查 10s,要求我这边协助排查优化. 二.问题 S ...
- mysql优化案例（14秒优化到不到1秒）
优化案例 前面用过的tbiguser表有10000000条记录 创建tuser1表和tuser2表,并初始化若干的数据. create table tuser1( id int primary key ...
最新文章
- python学习路线-Python学习路线
- 关于easyui中的editIndex
- 【Linux】14_文件打包及压缩
- Android开发者必备：推荐一款助力开发的开源APP
- 用Docker打造多版本PHP运行环境
- 笔记本网络计算机和设备不可见,xp电脑不显示无线网络的七种原因和解决方法...
- c盘所有的html文件全删,我将C盘文件夹全删了
- leetcode 242. 有效的字母异位词
- Python学习1——Python中的 split() 函数
- 朴素贝叶斯分类器的python实现
- 2018 蓝桥杯省赛 B 组模拟赛（五）题 B题
- java动态编译无法导包_java动态编译整个项目,解决jar包找不到问题.doc
- 使用百度统计分析你的网站访问数据
- tornado框架学习
- HDFS中的NameNode和DataNode
- 黑色精美大气DJ音乐歌曲网站源码+带WAP手机端
- ubuntu 安装UliPad
- 2022年中国工业机器人市场现状研究分析与发展前景预测报告
- 信息安全技术 网络安全漏洞分类分级指南（GB/T 30279-2020 ）
- 小程序组件传值方法调用