我有一些已分区的表，并且在复制的从属设备上有多个索引。将快照（已验证安全）复制到新从属并将 mysqld 从 5.1.42 升级到 5.5.15 并重新启动复制后，我收到 InnoDB 崩溃并显示错误消息“无效指针...”
这些错误发生在具有不同硬件和操作系统的 2 个服务器上。运行后：
ALTER TABLE .... COALESCE PARTION n;
那张桌子的问题就消失了。
不过，我的问题范围更大，那就是“您如何识别 InnoDB 表损坏？” 或改写为“您如何评估 InnoDB 表的健康状况？” 是“检查表”可用于识别问题预碰撞唯一的工具？
不确定它是否重要，但运行时发生崩溃：版本：'5.5.15-55-log' 套接字：'/opt/mysql.sock' 端口：3306 Percona Server (GPL)，版本 rel21.0，修订版 158
什么是 Percona？
它与 MySQL 有何不同？
我们什么时候应该考虑从库存 MySQL 切换（或升级）到 Percona？
为了在我们的情况下添加一些细节，我们几乎只使用具有广泛外键约束和一些存储过程的 InnoDB（我知道 Percona 已经做了很多优化）。
我们目前发现 MySQL 对我们的查询优化不佳，因此任何超过 3-4 个连接的查询我们都必须使用 STRAIGHT 连接显式构建以提高性能。
您好，我正在运行最新版本的 Percona Server。
服务器版本：5.5.24-55 Percona Server (GPL)，26.0 版
我有一个10个cpu的盒子有这些特点。
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 9
model name : AMD Opteron(tm) Processor 6128
stepping : 1
microcode : 0x10000d9
cpu MHz : 800.000
cache size : 512 KB
它具有 SSD 和 64GB 的 RAM。Innodb 大约为 10GB，因此 innodb_buffer_pool_size 设置为 10GB。
我有一张如下表：
create table TODAY
( symbol_id integer not null
, openp decimal(10,4)
, high decimal(10,4)
, low decimal(10,4)
, last decimal(10,4) not null
, volume …如果 Aria 存储引擎（以前称为 Maria）是“新的”MyISAM，它支持事务和自动崩溃恢复：
我用谷歌搜索并搜索了 stackexchange，但找不到与此特定问题相关的任何内容（还有其他错误 11 问题，就我所知，仅此而已）。
我们的服务器并没有真正进行大量的读取或写入。服务器是具有 16 个内核和 16GB 内存的 VM。
MySQL 在一段未知的时间后崩溃，错误日志显示：
09:17:14 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have …OLTP 数据库的硬件规格
软件规格
我的首要任务是数据完整性/保护，其次是性能。
在配置我们的新服务器（IBM X3650M4、2x Intel Xeon E5-2620、64G RAM、RAID 10（4x 240G SSD））时，我们遇到了一个奇怪的问题。我们试图将转储 ( mydumper) 从我们的（旧）生产环境导入到我们的新环境中，但我们几乎无法这样做。
转储为47G（压缩），+/- 4500 个表，最大的表为 7.1G（54285914 行）、2.2G、1.7G 和 1.7G。
我们试图myloader用 12 个（或 8 个）线程运行，但大多数时候都失败了。几分钟后，myloader遇到大桌子和摊位。一些工具显示没有更多活动（htop没有 CPU 负载，iostat没有写入或读取），mytop显示 4 个（长时间运行）永远不会完成的查询，大多数innotop屏幕都被冻结（因为SHOW INNODB STATUS不再返回任何结果）。当我尝试重新启动时mysql也失败了，因为mysql无法杀死多个线程。唯一的补救方法是使用killall -9 mysqld mysql.
我们正在使用以下 mysql 配置：
# cat /etc/mysql/my.cnf
# Ansible managed
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
ssl_cert = /etc/mysql/client-cert.pem
ssl_key = …我最近遇到了以前从未见过的 MySQL 情况。我们有一个有 3 个节点的 Percona 集群。master 停止处理查询，我们托管的 PHP FPM Web 应用程序变得无响应。当我检查时SHOW PROCESSLIST，MySQL 进程卡在状态：wsrep: initiating replication for write set (-1)
PHP 将所有查询定向到的主数据库和两个辅助数据库之一都是这种情况。这是我看到的输出SHOW PROCESSLIST：
mysql> show processlist;
+-------+-------------+--------------------+-----------------+---------+-------+--------------------------------------------------------+--------------------------------------------------------------------------------------+-----------+---------------+
| Id | User | Host | db | Command | Time | State | Info | Rows_sent | Rows_examined |
+-------+-------------+--------------------+-----------------+---------+-------+--------------------------------------------------------+--------------------------------------------------------------------------------------+-----------+---------------+
| 1 | system user | | NULL | Sleep | 2171 | wsrep: committing write set (542480920) | NULL | 0 | 0 |
| …我abc在 mysql 服务器中有一个数据库。它只有一张名为test. test使用 innodb 引擎，我已经设置innodb_file_per_table为 true。
运行查询后delete from abc.test，我想计算abc. 这是我使用的查询：
SELECT
table_schema "name",
sum( IF(engine = "MyISAM", data_length + index_length - data_free,
data_length + index_length)) "size"
FROM information_schema.TABLES
where table_schema like "abc";
奇怪的是，我发现数据库大小根本没有减少，但是“测试”中的数据却不见了。
我做过很多次这种测试，这种奇怪的行为有时会发生。
我正在使用 percona mysql server 5.5.29-rel29.4.
谁能告诉我出了什么问题？
更新：
实际上，我使用另一个线程定期检查数据库大小。
我是社交媒体 SAAS 的技术负责人，目前我们正在体验存储在 mySQL 数据库中的数据量大幅增加。
我们只有一个MySQL数据库，除了许多非常小的表外，我们还有两个大约500k-1.5m行的表。
目前，在执行 DDL 查询（向这些表添加新列）时，我们必须处理相当长的执行时间(around 4-5 mins)。
我开始搜索在线模式迁移技巧，发现以下内容：
尽管这些策略值得研究，但我开始感到不舒服：我不认为，行数如此之少的表必须使用如此高级的方法。（那么真正巨大的桌子呢？）
所以我想知道，你们中是否有人有关于 mysql.cnf 本身的提示，或者 ddl 查询的其他性能提示？