标签: tokudb

我已将具有 80.000.000 行的 MySQL 数据库转换为 TokuDB。

现在当我运行时：

 select count(id) from xxx where active=1

它占用了正常 MySQL 请求的 90% 的时间。

我需要进一步优化什么才能让它运行得更快？

表定义：

CREATE TABLE `adsDelivered` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `uid` varchar(40) NOT NULL,
  `_adsDelivered` bigint(20) NOT NULL DEFAULT '0',
  `_campaign` bigint(20) NOT NULL DEFAULT '0',
  `_ad` bigint(20) NOT NULL DEFAULT '0',
  `session` varchar(44) NOT NULL,
  `referer` text NOT NULL,
  `refererDomain` varchar(256) NOT NULL,
  `pageTime` int(11) NOT NULL DEFAULT '0',
  `pageVisibleTime` int(11) NOT NULL DEFAULT '0',
  `browser` varchar(256) NOT NULL,
  `ip` …

正在optimize table对我的一个大约 11Gig 大小的表运行命令时，令人惊讶的是，在优化过程完成后，使用的磁盘空间立即增加了 2Gig。我希望优化能够回收空间。

发生了什么？

优化完成后，MySQL CPU 利用率比以前高 2-3 倍，在 24 核机器上平均负载为 18-20。几个小时后，CPU 和平均负载略有下降，但仍高于平时。有没有类似经历的？谢谢。

我有下表。

我也想加分区。

CREATE TABLE `app_log_Test` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `dateCreated` datetime NOT NULL,
  `host` varchar(512) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `label` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `event` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `level` varchar(8) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `message` text COLLATE utf8mb4_unicode_ci,
  `version` bigint(20) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `app_log_dateCreated` (`dateCreated`),
  KEY `app_log_label` (`label`),
  KEY `app_log_event` (`event`),
  KEY `app_log_level` (`level`)
) ENGINE=TokuDB `COMPRESSION`=tokudb_quicklz

我正在使用 MariaDB 10。

MariaDB [test2]> alter table app_log_Test partition by RANGE(TO_DAYS(dateCreated))(
-> PARTITION …

我有一个大约有 8.5m 行的表格。该表是 tokudb，它具有下面描述的索引。在尝试运行如下更新语句时，我遇到了令人沮丧的性能：

 update retail.lw_item_discovery 
 set price = 'X', 
     prev_price = 'Y', 
     last_updated = '2016-04-13', 
     last_price_change = '2016-04-13' 
 where market = 'XX' 
   and sku = '123456'

执行此更新需要 40 秒以上的时间。还有其他类似的更新经常发生，但是这台机器的 I/O 子系统并没有受到丝毫压力（RAID SSD），并且还有大量可用的 RAM。

EXPLAIN 产量：

 update retail.lw_item_discovery 
 set price = 'X', 
     prev_price = 'Y', 
     last_updated = '2016-04-13', 
     last_price_change = '2016-04-13' 
 where market = 'XX' 
   and sku = '123456'

基于此 - 它选择PRIMARY索引而不是其他索引之一，例如cl_unique_idx在前两个位置的 where 语句中具有两列的索引。所以我很难过为什么计划者选择了PRIMARY而不是导致性能如此糟糕。以下是索引列表：

+----+-------------+-------------------+------------+-------+------------------------------------------------------------+---------+---------+------+------+----------+------------------------------+
| id | select_type | table             | partitions | …