MySQL 没有充分利用服务器

Question

我在 Amazon RDS db.m4.xlarge（16Gb RAM，4vCPU）多可用区部署上运行 MariaDB 10.0.17。我们使用最大设置为 10000 IOPS 的预置 IOPS 存储。 users 表包含 17M 条记录； user_properties 表包含 350M 条记录。

user_properties 表描述了附加到用户的道具的“地图”。 upkey 是键，string_value、integer_value 等是每种类型的值；字符串、日期、整数、双精度。索引也是每种类型的。

我们尝试向user_properties 表插入更多数据：应用程序将数据插入INNODB 临时表TEMP1，然后将数据从TEMP1 复制到user_properties 表。

问题是我们只能达到 2500 写入 IOPS 和 500-1000 读取 IOPS。队列深度平均保持在 7 左右。 MySQL 服务器 CPU 使用率保持在 20-30%，从未达到 60%。 应用程序似乎向 MySQL 提供了足够的数据：我们将类似的数据文件提供给 DB，并查看处理时间如何随着表大小的增加而增加。 大多数时间应用程序等待 MySQL 查询完成。在这个过程中，插入TEMP1 表只需要一小部分时间，大部分时间是等待从TEMP1 表插入到user_properties。

有人可以帮我加快 MySQL 的速度吗？我应该增加/改变什么？

CREATE TABLE IF NOT EXISTS `users` (
  `id` bigint(20), // Column is not used now. Filled with NULL
  `version` bigint(20) NOT NULL,
  `email` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `uuid` varchar(80) COLLATE utf8_unicode_ci DEFAULT NULL,
  `partner_id` bigint(20) NOT NULL,
  `password` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `date_created` datetime DEFAULT NULL,
  `last_updated` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `unique-email` (`partner_id`,`email`),
  UNIQUE KEY `users_Uuid` (`uuid`),
  KEY `idx_013_partner_id_uuid` (`partner_id`,`uuid`),
  KEY `idx_014_uuid` (`uuid`),
  CONSTRAINT `FKB2D9FEBE725C505E` FOREIGN KEY (`partner_id`) REFERENCES `partner` (`id`),
  CONSTRAINT `fk_046_partner` FOREIGN KEY (`partner_id`) REFERENCES `partner` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;


CREATE TABLE IF NOT EXISTS `user_properties` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `version` bigint(20) NOT NULL,
  `date_created` datetime DEFAULT NULL,
  `last_updated` datetime DEFAULT NULL,
  `upkey` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `user_id` bigint(20) DEFAULT NULL,
  `security_level` int(11) NOT NULL,
  `_content` longtext COLLATE utf8_unicode_ci NOT NULL,
  `class` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `date_value` datetime DEFAULT NULL,
  `integer_value` bigint(20) DEFAULT NULL,
  `double_value` double DEFAULT NULL,
  `string_value` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `uuid` varchar(80) COLLATE utf8_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `idx_004_uuid` (`uuid`),
  KEY `idx_005_string_value` (`upkey`,`string_value`),
  KEY `idx_006_integer_value` (`upkey`,`integer_value`),
  KEY `idx_007_double_value` (`upkey`,`double_value`),
  KEY `idx_008_date_value` (`upkey`,`date_value`),
  KEY `idx_key_value_user_upkey_string` (`user_id`,`upkey`,`string_value`),
  CONSTRAINT `FK_users` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Answer 1

您需要id 和uuid 吗？我认为不会。

一张桌子需要 3 个 UNIQUE 键吗？我想不是。 （记住PRIMARY KEY 是UNIQUE。）

uuid 在表变​​得很大时有一些非常糟糕的 I/O 属性。重新考虑您对它们的使用。 uuid 上的索引是非常随机的。当索引（或表）变得太大而无法放入 buffer_pool 时，提取往往涉及 I/O 而不是被缓存。对于 350M 行和 16GB RAM，我怀疑性能问题的很大一部分是由于 uuid。

user_properties 是一个“键值”存储，对吗？这种模式设计模式很糟糕。什么是典型的SELECT？我怀疑是这样的：

SELECT ..._value FROM user_properties
    WHERE user_id = '...'
      AND upkey = '...';

假设这是正确的，性能可以通过具有一些改进

PRIMARY KEY(user_id, upkey, id)

这会将给定用户的键值对“聚集”在一个位置（可能是 1-2 个块），从而加快获取速度。

更多关于evils of key-value 和改进建议。
更多关于evils of UUIDs。