MySQL分析：使用AI驱动的CLI工具
本文是 https://anothermysqldba.blogspot.com/2025/07/mysql-analysis-with-ai-powered-cli-tool.html 的中文翻译版。
作为MySQL DBA，我们经常在Linux终端窗口中工作。我们也喜欢可用的免费选项。这篇文章展示了一种方法，让我们可以在终端窗口中使用AI驱动的工具。你可以更新使用其他直接的AI提供商，但我将此示例设置为使用aimlapi.com，因为它免费提供有限使用的多个AI模型到你的终端，或者以很低的成本进行更多测试。
注：我不是AIMLAPI的付费发言人或任何其他身份 - 这只是一个简单的例子来突出这个想法。
问题
你正在查看一个有数百个表的遗留数据库，每个表都有复杂的关系和多年前做出的可疑设计决策。通常的过程包括：
巡检工作是保障系统平稳有效运行必不可少的一个环节，目的是能及时发现系统中存在的隐患。我们生活中也随处可见各种巡检，比如电力巡检、消防检查等，正是这些巡检工作，我们才能在稳定的环境下进行工作、生活。巡检对于数据库或者其他IT系统来说也同样至关重要，特别是在降低风险、提高服务稳定性方面起到了非常关键作用。
本文介绍了美团MySQL数据库巡检系统的框架和巡检内容，希望能够帮助大家了解什么是数据库巡检，美团的巡检系统架构是如何设计的，以及巡检系统是如何保障MySQL服务稳定运行的。
一、背景
为了保障数据库的稳定运行，以下核心功能组件必不可少：
图1 数据库运维保障核心功能组件
…
[获取更多]| 按照重要程度划分数据库级别 | |||||
| 级别 | D | C | B | A | S |
| 影响面 | 小于10人 | 10-1000人 | 1000-100000人 | 100000-1000000人 | 1000000人以上 |
| 业务类型举例 | 测试/开发系统，小型OA 记账软件等 | 中型OA ERP 财务软件等 | 中大型ERP MES HRM ，大型医院HIS | 电信CRM 银行BANKING等 | 大型公共应用 如12306等 |
| 灾难救援价格 | 500-5000 | 5千到三万 | …
有个疑似 OCD 患者最近抽风升级了一下 MySQL 数据库，然后发现 blog 里面全都变成了乱码。
那乱码的模式一看就是把 utf8 直接扔进了 latin1 的数据库，一看 SHOW CREATE TABLE mt_entry 发现果然如此。
略有些慌神，看了 MySQL 文档发现用 ALTER TABLE 的 CONVERT TO 硬来有点不太行好，遂想到可以试试看 mysqldump，于是做了：
当作 latin1(不然会再按 utf8 编码一次)：
mysqldump mt_delphij –default-character-set=latin1 -r utf8.dump
把里面的 CHARSET=latin1 替换为 CHARSET=utf8：
sed -e s,CHARSET=latin1,CHARSET=utf8,g < utf8.dump > utf8.dump.edited
删掉其中的 SET NAMES latin1。
然后重新导入：
mysql -uroot -p --default-character-set=utf8 mt_delphij …[获取更多]
这只是一条注释，旨在帮助可能会在其自动化工具中使用mysql_config_editor命令的任何人。
mysql_config_editor不使用密码参数，因此在尝试使用mysql_config_editor的.my.cnf文件中设置密码之前可能拥有的自动化工具会失败。
尽管使用期望工具，这是可能的并且非常简单。
yum -y install expect
它也适用于apt-get。
因此，在此示例中，我将显示一个简单的bash脚本版本。
1 ..我的登录路径不起作用...
mysql --login-path=local
ERROR 1045 (28000): Access denied for user
设置这个与期望
您可以通过bash脚本执行此操作。
expect <<EOD
spawn mysql_config_editor set …
MySQL和Docker ...不是新概念，人們已經使用Docker已有一段時間了。
對於剛開始為此發展的人來說，可能會有一些障礙。
儘管MySQL在本地運行良好，但如果要在不同版本的MySQL上測試代碼，則很容易擁有多個版本是很好的。
多年來，一種選擇當然是Giuseppe Maxia的https://mysqlsandbox.net/ 。
這是一個非常有效的解決方案，能夠啟動多個實例並測試複製等。
在跨不同版本的MySQL進行測試時，Docker現在也是另一個經常使用的場景。 下面僅介紹一些步驟，以輕鬆安裝多個版本。
我使用OSX，因此這些示例適用於OSX。
…
前言
MySQL 的 innodb 引擎之所以使用 B+tree 来存储索引，就是想尽量减少数据查询时磁盘 IO 次数。树的高度直接影响了查询的性能。一般树的高度在 3~4 层较为适宜。数据库分表的目的也是为了控制树的高度。那么如何获取树的高度呢？下面使用一个示例来说明如何获取树的高度。
示例数据准备
建表语句如下：
CREATETABLE`user` ( `id` int(11) NOTNULLAUTO_INCREMENT, `name` varchar(100) CHARACTERSETlatin1 DEFAULTNULL, `age` int(11) DEFAULTNULL, PRIMARYKEY(`id`), KEY`name` (`name`), KEY`age` (`age`) ) ENGINE=InnoDB DEFAULTCHARSET=utf8
表中插入100万条数据。数据如下：
mysql> select* fromuserlimit 2\G *************************** 1. row *************************** id: 110000 name: ab age: 100 *************************** 2. row *************************** id: 110001 name: ab age: 100 2 …[获取更多]
MySQL如何恢復表空間？
這不是新的信息，但我沒有多說，所以現在為那些需要它的人解決它。
如果您丟失了ibd文件......您將丟失數據。 因此，如果您有一個可用的副本..或者即使您從另一個數據庫同步，您仍然可以導入它。
什麼/你如何失去表空間？
這是一個恢復表空間的簡單示例。
mysql> Create database demo;
mysql> use demo;
mysql> CREATE TABLE `demotable` (
-> `id` int(11) NOT NULL AUTO_INCREMENT,
-> `dts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON
UPDATE CURRENT_TIMESTAMP,
-> PRIMARY KEY (`id`)
-> ) ENGINE=InnoDB;
現在我們存儲一些數據......
mysql> INSERT INTO demotable (id) VALUES (NULL);
Query OK, 1 row affected (0.10 …
所以我意識到在最近出現這種情況後我沒有發表過關於此的帖子。
以下是場景：在午夜進行備份，他們使用每個數據庫的MySQL轉儲。 然後在第二天上午十點數據庫崩潰。
在我被調用之前發生了一系列事件，但他們把它帶到了MyISAM表的數據庫版本和表空間中缺少的IBD文件。
所以選項1，從備份恢復會讓我們到午夜，我們會丟失數小時的數據。 選項2，我們重新導入1000的ibd文件並保留所有內容。
然後我們有選項3，從備份恢復，然後應用binlogs進行最近的更改。
為了使它更有趣，他們沒有我被告知的所有ibd文件，我確實看到一些丟失。 所以不確定這是怎麼可能的，但是選項2變成了無效選項。
當然，他們希望盡可能減少數據丟失，因此我們選擇了3。
…
所以MySQL的組複製出來了MySQL 5.7。 現在已經有一段時間了，人們開始更多地詢問它。