标签: myisam

是否可以从我的庞大数据库 (mysql) 中删除所有空表？

我正在寻找一个 sql 命令来自动删除所有这些空表。

目前，我的数据集中有 305 个表，其中大约 30% 是旧的空表，不会在我的新应用程序中使用。

只是为了澄清；所有表的类型都是=MyISAM

我从一个示例配置文件中读取了以下内容：

# Sort buffer is used to perform sorts for some ORDER BY and GROUP BY
# queries. If sorted data does not fit into the sort buffer, a disk
# based merge sort is used instead - See the "Sort_merge_passes"
# status variable. Allocated per thread if sort is needed.

我有几个使用文件排序的查询。如何确定查询在不碰到磁盘的情况下顺利运行所需的缓冲区大小是多少？

我没有按照我的意愿进行全文搜索，而且我不明白结果列表中的差异。

示例语句：

SELECT `meldungstext`
FROM `artikel`
WHERE `meldungstext` LIKE '%punkt%'

返回 92 行。我在meldungstext 列中收到具有匹配项的行，例如“Punkten”、“Zwei-Punkte-Vorsprung”和“Treffpunkt”。

我在“meldungstext”列上设置了全文索引并尝试了这个：

SELECT `meldungstext`
FROM `artikel`
WHERE MATCH (`meldungstext`)
AGAINST ('*punkt*')

这仅返回 8 行。我只收到与“Punkt”本身或我认为在“i-Punkt”中被视为“Punkt”的单词匹配的行。

然后我尝试了布尔模式：

SELECT `meldungstext`
FROM `artikel`
WHERE MATCH (`meldungstext`)
AGAINST ('*punkt*' IN BOOLEAN MODE)

返回 44 行。我收到的行在列 meldungstext 中包含“Zwei-Punkte-Vorsprung”或“Treffpunkt”，但没有包含“Punkten”的行。

为什么会发生这种情况，如何设置“完全”工作的全文搜索以防止在 where 子句中使用 LIKE '%%'？

问题

MySQL 5.6.20 的一个实例运行（主要是）一个包含 InnoDB 表的数据库，在 1-4 分钟的持续时间内，所有更新操作偶尔会出现停顿，所有 INSERT、UPDATE 和 DELETE 查询都保持在“查询结束”状态。这显然是最不幸的。MySQL 慢查询日志甚至会记录具有疯狂查询时间的最琐碎的查询，其中数百个具有与解决停顿的时间点相对应的相同时间戳：

# Query_time: 101.743589  Lock_time: 0.000437 Rows_sent: 0  Rows_examined: 0
SET timestamp=1409573952;
INSERT INTO sessions (redirect_login2, data, hostname, fk_users_primary, fk_users, id_sessions, timestamp) VALUES (NULL, NULL, '192.168.10.151', NULL, 'anonymous', '64ef367018099de4d4183ffa3bc0848a', '1409573850');

并且设备统计数据显示增加，尽管在此时间范围内没有过多的 I/O 负载（在这种情况下，根据上述语句中的时间戳，更新在 14:17:30 - 14:19:12 停止）：

# sar -d
[...]
02:15:01 PM       DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
02:16:01 PM    dev8-0     41.53    207.43   1227.51     34.55      0.34      8.28      3.89     16.15
02:17:01 PM    dev8-0     59.41    137.71 …

我已准备好从 MyISAM 迁移到 InnoDB，但想知道是否有要查找的完整列表？例如，我没有看到任何列表提到DISABLE KEYS在 InnoDB 表上运行会抛出警告，除了ALTER TABLE. 这是我在转换之前需要了解的那种事情。我以为我可以接受我的查询，但显然不是。

我正在运行 MySQL 服务器，以在 Debian 作为来宾操作系统的 VM (VMWare) 上进行测试。来宾有四个模拟 CPU 内核，因此我将 thread_concurrency 设置为四个。

我在大型表上执行昂贵的连接，这可能需要几分钟，但我在来宾操作系统上看到，一次只使用一个核心。无论用于所涉及的表的存储引擎如何（使用 MyISAM 和 InnoDB 测试），都会发生这种情况。此外，在执行这些大型查询时，整个数据库似乎都被阻塞了，我无法并行执行任何其他查询。奇怪的是 htop 显示，用于查询的核心在查询运行时发生了变化！

为什么会发生这种情况？

这是来自SHOW FULL PROCESSLIST;（没有其他查询）的相关条目：

| 153 | root       | localhost | pulse_stocks  | Query   |   50 | Copying to tmp table | 
SELECT DISTINCT * FROM 
`pulse_stocks`.`stocks` sto,
`pulse_new`.`security` sec
WHERE
(sto.excntry = sec.excntry AND sto.stock_id = sec.ibtic) OR
( sto.isin = sec.isin AND sto.isin <> "" AND sec.isin <> "" )
ORDER BY
sto.id
LIMIT 0, 30 

没有其他待处理的查询。另一个有趣的观察是，如果我省略这 …

我有一个大约 100 个表的数据库来存储各种信息。

最重要的表是我们的订单表，用于存储客户订单，截至目前已超过 100000 条记录，并且还在不断增长。

该表是我们数据库中查询最多的表，用于获取实时订单仪表板、统计数据、分析等所需的各个部分信息。

我定期监视数据库，并在数据库上启用慢速查询以跟踪问题。

我每天都使用像 mysqltuner 这样的脚本来输出查询。

我还使用 mysqlsla 收集有关我们数据库中前 10 个最慢查询的信息。

sample stat
Count         : 11.48k  (30.66%)
Time          : 19.623758 s total, 1.709 ms avg, 239 µs to 2.475017 s max  (18.64%)
  95% of Time : 5.246833 s total, 481 µs avg, 239 µs to 1.095 ms max
Lock Time (s) : 14.460071 s total, 1.259 ms avg, 53 µs to 2.462555 s max  (41.38%)
  95% of Lock : 806.43 ms total, 74 µs avg, …

有一个大小为 500GB 的数据库 A。数据库 A 中的表包含 MyISAM 和 INNODB 表。MyISAM 表是主表，Innodb 表是主事务表。

使用 mysql dump 进行备份和恢复需要很长时间或几天才能退出。

• max_allowed_pa​​cket=1G
• Foreign_key_checks=0
• 自动提交 = 关闭

寻找一种策略或工具来处理在繁忙的复制系统中将单个数据库恢复到某个时间点的问题。

我有 12 个数据库在主从复制配置中的 2 个 MySQL 5.0.77 服务器上运行。每天对只读从站进行完整转储，并且有可用的增量 SQL 转储，这些备份是异地备份，复制状态受到监控。

编辑：表是 InnoDB 和 myISAM 的混合体，因此引擎特定的解决方案不可用。

因此，如果主服务器完全故障，我可以中断复制并提升从服务器，我还可以选择重建新服务器并从越位完整备份进行配置，然后应用从从服务器每小时获取的差异。

但是我担心如何处理部分故障或单个数据库的故障。我可以想到 2 个很有可能的场景；

1. 数据库 7（例如）损坏，继续处理一些请求，直到有人注意到它已损坏，或从日志文件中发出警报...
2. 一些查询，如删除数据库、删除表、“更新哪里...”类型的查询会占用单个数据库或其中的某个子集。

目前我有一堆完整的转储作为 FULL-$DATE-all-databases.sql.gz 文件，以及可以应用于完整转储的差异作为 DIFF-$DATE-all-databases.sql.gz

要将数据库 7 恢复到某个时间点，需要通过 FULL 和 DIFF 文件进行 grep，并手动应用该 sql。

我应该如何继续以便能够恢复到以前的 DIFF 转储之一到主数据库？

我需要备份到单个数据库文件，即

mysqldump --databases "database1" | gzip > database1.sql.gz
mysqldump --databases "database2" | gzip > database2.sql.gz
mysqldump --databases "database3" | gzip > database3.sql.gz

而不是..

mysqldump --master-data --lock--all-databases --all-databases | gzip > all-databases.sql.gz

如果我使用单独的 mysqldump 文件，主数据二进制日志会发生什么，我什至应该为主服务器恢复转储设置 --master-data 吗？

将客户的数据库移动到额外的服务器后，我们遇到了问题。这应该会对站点的性能产生积极的影响，但是 MyISAM 中的表锁定存在问题。（我听说过使用 InnoDB 代替 MyISAM，但我们不能在不久的将来更改引擎）。
我们可以发现它是一个更新查询，当主持人在文章站点上激活评论时执行该查询。这是过程：

• 处理更新查询 SET status = 1 WHERE id = 5（设置索引）
• 页面缓存文件被删除

此时整个页面变得缓慢。数据库本身忙了几分钟。我取了几次进程列表，看到大约 60 个不同选择查询的条目，它们都处于等待表级锁定的状态。

1.我不明白为什么表上的这个更新article_comments会影响表的选择语句article以等待表级锁。在 processlist 中，几乎所有等待的查询都来自该表。我已经读过更新/插入比选择更受欢迎的事实，这可能会导致此类问题，但是当评论被激活时，文章表本身不会更新，因此选择不应该等待。我误解了吗？
2. 除了更改为 InnoDB 之外，还有什么可以防止这种行为或至少是为了获得更好的平衡吗？我对在将数据库移动到新服务器之前没有出现这个问题感到非常恼火。我想有一些配置错误，但我不知道如何识别。