标签: percona-server

我刚刚发现table_definition_cache并且我正在尝试决定将其设置为什么。由于性能问题，我弄乱了我的配置。

在一台服务器上，我有 36599 个表，当我运行SHOW GLOBAL STATUSOpened tables 的值是 930312。table_definition_cache设置为 20k。

在另一台服务器上，我有 45349 个表，当我运行SHOW GLOBAL STATUSOpened tables 的值是 94383。table_definition_cache设置为 40k。

我不确定将它设置为什么table_definition_cache值，因为服务器似乎做了很多打开/交换。

两台服务器都是 CentOS 6 并且正在运行

服务器版本：5.6.32-78.0 Percona Server (GPL)，78.0 版，修订版 8a8e016

感谢您的关注！我非常感谢您的反馈。

我正在从 Ubuntu 服务器安装运行 Percona-Server 实例。我正在使用一个需要访问这个数据库的应用程序，它的性能非常差。一旦建立了数据库，应用程序就会进入（安装时）并创建模式。它将所有内容默认为 MyISAM，但是我已将表引擎转换回 InnoDB。我遇到的问题是插入性能非常差。这个应用程序的写入量非常大，似乎它一次将每一行 1 写入磁盘，而不使用任何类型的缓冲区，但是我不确定如何检查或验证这一点。即使从其中一个表中选择（*）也需要 2.4 秒，并且只有 163,000 行。我有点不知所措，我还能做什么。

服务器有 8GB 的​​内存，在发生这种情况时 CPU 几乎完全空闲。

我的.cnf：

[mysql]

# CLIENT #
port                           = 3306
socket                         = /var/run/mysqld/mysqld.sock

[mysqld]

# GENERAL #
user                           = mysql
default_storage_engine         = InnoDB
socket                         = /var/run/mysqld/mysqld.sock
pid_file                       = /var/run/mysqld/mysqld.pid

# MyISAM #
key_buffer_size                = 32M
myisam_recover                 = FORCE,BACKUP

# SAFETY #
max_allowed_packet             = 16M
max_connect_errors             = 1000000
skip_name_resolve
sql_mode                       = STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_AUTO_VALUE_ON_ZERO,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ONLY_FULL_GROUP_BY
sysdate_is_now                 = 1
innodb                         = FORCE
innodb_strict_mode             = 1

# DATA STORAGE # …

当我想创建表时，我安装了 Percona Server 5.6.12-rc60.4，例如：

CREATE TABLE IF NOT EXISTS `mydb`.`table` (
`id` INT NOT NULL AUTO_INCREMENT ,
`title` VARCHAR( 64 ) NOT NULL ,
PRIMARY KEY ( `id` ) 
) ENGINE = XtraDB DEFAULT CHARACTER SET = utf8 COLLATE = utf8_unicode_ci;

发生此错误：

 #1286 - Unknown storage engine 'XtraDB' 

如何使用 XtraDB 引擎创建表？

（在你骂我白痴或开始大笑之前，请记住这对我来说是一笔真正的交易，我不能取消这个任务，因为它是一个更大项目的一部分）

我有一个数据库服务器，它的大小非常大，并且在非常小的服务器上运行，即。32GB 内存，24 核。在周末期间，我们将向机器添加 18GB 的​​ RAM 以使其更强大（白天的服务器负载跃升至平均 80 ！！），直到我们解决使用该数据库的应用程序的性能问题。

我怀疑负载是由 DB 引起的，因为缺少可用 RAM（SWAP 中总是有大约 5GB）。

这个数据库有多个小表和一个巨大的表，它以大约 350,000 条记录/小时的速度接收 GPS 和 IO 数据，并且这个表按分区/月进行分区。

Mysqltuner 建议在所有表上运行优化表，但我读过在 InnoDB 表上这样做是无用的，而且需要很长时间。

这是脚本输出的一个片段：

General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Reduce your overall MySQL memory footprint for system stability
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_cache gradually to avoid file descriptor limits
Variables to …

我有一个大约有 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 | …