【问题标题】:MySql performance suggestionsMySql 性能建议
【发布时间】:2011-01-06 17:04:04
【问题描述】:

我不是 MySQL 专家,我遇到了问题。我有一张表,目前有 16GB 的数据,而且还会进一步增长。表结构如下,

CREATE TABLE `t_xyz_tracking` (
`id` BIGINT(20) NOT NULL AUTO_INCREMENT,
`word` VARCHAR(200) NOT NULL,
`xyzId` BIGINT(100) NOT NULL,
`xyzText` VARCHAR(800) NULL DEFAULT NULL,
`language` VARCHAR(2000) NULL DEFAULT NULL,
`links` VARCHAR(2000) NULL DEFAULT NULL,
`xyzType` VARCHAR(20) NULL DEFAULT NULL,
`source` VARCHAR(1500) NULL DEFAULT NULL,
`sourceStripped` TEXT NULL,
`isTruncated` VARCHAR(40) NULL DEFAULT NULL,
`inReplyToStatusId` BIGINT(30) NULL DEFAULT NULL,
`inReplyToUserId` INT(11) NULL DEFAULT NULL,
`rtUsrProfilePicUrl` TEXT NULL,
`isFavorited` VARCHAR(40) NULL DEFAULT NULL,
`inReplyToScreenName` VARCHAR(40) NULL DEFAULT NULL,
`latitude` BIGINT(100) NOT NULL,
`longitude` BIGINT(100) NOT NULL,
`rexyzStatus` VARCHAR(40) NULL DEFAULT NULL,
`statusInReplyToStatusId` BIGINT(100) NOT NULL,
`statusInReplyToUserId` BIGINT(100) NOT NULL,
`statusFavorited` VARCHAR(40) NULL DEFAULT NULL,
`statusInReplyToScreenName` TEXT NULL,
`screenName` TEXT NULL,
`profilePicUrl` TEXT NULL,
`xyzId` BIGINT(100) NOT NULL,
`name` TEXT NULL,
`location` VARCHAR(200) NULL DEFAULT NULL,
`bio` TEXT NULL,
`url` TEXT NULL COLLATE 'latin1_swedish_ci',
`utcOffset` INT(11) NULL DEFAULT NULL,
`timeZone` VARCHAR(100) NULL DEFAULT NULL,
`frenCnt` BIGINT(20) NULL DEFAULT '0',
`createdAt` DATETIME NULL DEFAULT NULL,
`createdOnGMT` VARCHAR(40) NULL DEFAULT NULL,
`createdOnServerTime` DATETIME NULL DEFAULT NULL,
`follCnt` BIGINT(20) NULL DEFAULT '0',
`favCnt` BIGINT(20) NULL DEFAULT '0',
`totStatusCnt` BIGINT(20) NULL DEFAULT NULL,
`usrCrtDate` VARCHAR(200) NULL DEFAULT NULL,
`humanSentiment` VARCHAR(30) NULL DEFAULT NULL,
`replied` BIT(1) NULL DEFAULT NULL,
`replyMsg` TEXT NULL,
`classified` INT(32) NULL DEFAULT NULL,
`createdOnGMTDate` DATETIME NULL DEFAULT NULL,
PRIMARY KEY (`id`),
INDEX `id` (`id`, `word`),
INDEX `word_index` (`word`) USING BTREE,
INDEX `classified_index` (`classified`) USING BTREE,
INDEX `createdOnGMT_index` (`createdOnGMT`) USING BTREE,
INDEX `location_index` (`location`) USING BTREE,
INDEX `word_createdOnGMT` (`word`, `createdOnGMT`),
INDEX `timeZone` (`timeZone`) USING BTREE,
INDEX `language` (`language`(255)) USING BTREE,
INDEX `source` (`source`(255)) USING BTREE,
INDEX `xyzId` (`xyzId`) USING BTREE,
INDEX `getunclassified_index` (`classified`, `xyzType`) USING BTREE,
INDEX `createdOnGMTDate_index` (`createdOnGMTDate`, `word`) USING BTREE,
INDEX `links` (`links`(255)) USING BTREE,
INDEX `xyzType_classified` (`classified`, `xyzType`) USING BTREE,
INDEX `word_createdOnGMTDate` (`word`, `createdOnGMTDate`) USING BTREE
    )COLLATE='utf8_general_ci'
    ENGINE=InnoDB
    ROW_FORMAT=DEFAULT
    AUTO_INCREMENT=17540328

此表上的查询现在运行缓慢,我预计它们会进一步减慢,我的服务器配置如下所示,

Intel Xeon E5220 @2.27GHz(2 个处理器) 12GB 内存 Windows 2008 服务器 R2

my.ini 文件详情如下,

default-storage-engine=INNODB
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
max_connections=300
query_cache_size=0
table_cache=256
tmp_table_size=205M
thread_cache_size=8
myisam_max_sort_file_size=3G
myisam_sort_buffer_size=410M
key_buffer_size=354M
read_buffer_size=64K
read_rnd_buffer_size=256K
sort_buffer_size = 64M
join_buffer_size = 64M
thread_cache_size = 8
thread_concurrency = 8
query_cache_size = 128M
innodb_additional_mem_pool_size=15M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=30M
innodb_buffer_pool_size=6G
innodb_log_file_size=343M
innodb_thread_concurrency=44
max_allowed_packet = 16M
slow_query_log
long_query_time = 6

可以做些什么来提高性能,

  1. 转换为 MyISAM 表有帮助,我有 INNODB,因为该表经常写入,甚至更频繁地读取。
  2. 我注意到磁盘 I/O 很高,有时高达 20-40MB/秒

谢谢, 罗希特

【问题讨论】:

标签: mysql performance mysql-management


【解决方案1】:

一个建议是运行

SELECT * FROM t_xyz_tracking PROCEDURE ANALYSE()

PROCEDURE ANALYSE 将根据表中的数据告诉您表中列的建议类型。这应该有助于提高您的效率。

【讨论】:

  • 我不知道这件事。太好了。
  • 是的。我很确定您可以摆脱大多数 BIGINT 以支持 INT 甚至可能是 MEDIUMINT。
【解决方案2】:

所有可以为 NULL 的列都可能被移动到单独的表中。检查每列中值的百分比为 NULL,如果它相对较高 - 将其移动到单独的表中。

接下来,您可能需要考虑哪些列被频繁访问,哪些列被访问相对较少。很少使用的列也可以移动到单独的表中。

【讨论】:

    【解决方案3】:

    当你的 mysql 服务器太慢时,一个好主意是激活“慢查询日志”,然后研究其中显示的查询。

    这极大地帮助了我避免由于一些业余的书面查询而导致的一些可能的灾难性故障。

    【讨论】:

      【解决方案4】:

      就在我的脑海中,您似乎在不应该使用TEXT 类型。 TEXT 是一个 CLOB(认为 BLOB 仅用于字符)。如果你有一个 url,VARCHAR(255) 可能会更好。一个名字,50个字符还不够吗?

      运行缓慢的查询,它们是否在使用索引?

      您的“isXXX”字段可以更改为 BOOLEAN(或 tinyint(1))吗?

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2012-02-06
        • 2020-06-12
        • 2012-10-10
        相关资源
        最近更新 更多