标签: optimization

即使安装了 memcached 和 APC，服务器也需要 20 多秒（等待时间/缓慢的 IO 响应时间）来响应 HTTP 请求。我相信这与 MYSQL 有关系，因为该站点有很多INSERT查询。

任何帮助将不胜感激。提前致谢。

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
               6.38    0.03    1.05    0.40    0.00   92.14
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.37    0.00    1.61    3.14    0.00   84.87
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9.40    0.00    1.41    1.53    0.00   87.67
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.02    0.00    1.42    1.09    0.00   87.46
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           9.32    0.00    1.31    0.78    0.00   88.59 …

所以我有一张有很多外键的表，但是当我要记录时，我需要加入这些表上的所有内容，因为我通常需要这些字段才能使记录有意义。基本查询如下所示：

SELECT i.id, i.`key`, i.title, i.description,
CONCAT(ru.firstName, ' ', ru.lastName) as `name`,
CONCAT(au.firstName, ' ', au.lastName) as `name`,
p.title, pc.title, pva.title, pvo.title, pvf.title, i.durationEstimate,
i.storyPoints, i.dueDate, isl.title, i.rejectionCount,
CONCAT(uc.firstName, ' ', uc.lastName) as `name`,
i.createdTimestamp, i.updatedTimestamp, it.title, isss.title
FROM ProjectManagement2.Issues i
INNER JOIN Users ru ON ru.id = i.reporterUserUsername
INNER JOIN Users au ON au.id = i.assignedUserUsername
INNER JOIN Projects p ON p.id = i.projectTitle
INNER JOIN ProjectComponents pc ON pc.id = i.projectComponentTitle
INNER JOIN ProjectVersions pva ON pva.id = …

我继承了一个又大又慢的存储过程，它给了我一个噩梦：

我不是DBA，虽然我有一些知识，但我不知道从哪里开始识别这个瓶颈。

我的桌面上安装了 SQL Server 2008，并带有生产数据库的精确副本。我正在从 SSMS 运行所有内容，并且尝试过直接使用 SQL 和 SP。SP 与 SQL 的时间足够接近相同，不必担心 - 这是我关心的本地与服务器的时间。

本地:

• 2GHz 双核
• 4Gb 内存
• SQL Server 2008 Sp1
• Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0（英特尔 X86）
• Windows NT 6.1 上的企业版（内部版本 7601：Service Pack 1）

服务器:

• 2GHz 双核
• 4Gb 内存
• Microsoft SQL Server 2008 (SP1) - 10.0.2573.0 (X64)
• Windows NT 5.2（内部版本 3790：Service Pack 2）（VM）上的标准版（64 位）

当我“本地”运行时，大约需要10 分钟才能完成。

当我在服务器上运行时，大约需要14 个小时才能完成！！！

[总插入量约 = 14,000,000]

我已经尝试尽可能多地调整 SP 并避免参数嗅探，但不确定为什么这在几乎等效的机器上会慢得多（我知道 SQL Server 版本略有不同，但不明白为什么会这样）有那么大的不同？） …

这是简化的，但代表了我试图解决的问题。我们有一个包含 5-1000 万行的表格，其格式类似于以下内容...

Input Table
Date    Item   Moved to Box
Oct-1   1      BoxA 
Oct-6   1      BoxB
Oct-8   1      BoxC
Oct-9   1      BoxB
Oct-16  1      BoxC
Oct-17  1      BoxD

我正试图把它转换成这个

Expected Output
Item    Box    Duration
1       BoxA   5
1       BoxB   9
1       BoxC   2
1       BoxD   *unimportant

*查询返回的内容无关紧要BoxD（唯一的框移入而没有框移出），因为它被丢弃了。

对于示例，希望您可以看到输入表表示一个项目何时从一个盒子移动到另一个盒子的日志，并且预期输出是每个项目在每个盒子中花费的累积时间。

我的第一个想法是做一个表与自身的连接，并为每条记录做一些日期最小/最大，以尝试从框中找到退出日期，然后对结果求和，但这似乎是一个非常密集的过程。

有人将如何以有效的方式解决这个问题？

简单查询：

select sum(score) total,name,gender,dob,country 
from users join scores on users.id = scores.user_id
where date between '2012-01-01' and '2012-01-31 23:59:59'
group by scores.user_id having sum(score)>=1000 order by sum(score) desc limit 50

因此，尝试获取 2012 年 1 月的累积分数列表，按分数降序排列它们并对其进行分页。

无限制：缓慢但可以：搜索 69348 行。（很高兴弄清楚如何避免临时表，但我不能）。解释说：

1, 'SIMPLE', 'scores', 'range', 'user,date,user+date', 'date', '8', '', 69348, 'Using where; Using temporary; Using filesort'
1, 'SIMPLE', 'users', 'eq_ref', 'PRIMARY', 'PRIMARY', '8', 'scores.user_id', 1, 'Using where'

有限制：它是一样的，但行搜索现在是 1806794，它需要永远。

如果有任何区别，它是一个分区的 InnoDB，所有数据都在一个分区上。

我只是花了一些时间与一位同事讨论了两种可选的数据库设计，但我并不相信。我们都不是严格的 DBA，所以我们可能会遗漏一些东西。

总体目标是为三个（可能是 4 个）实体中的每一个创建附加开放式自由文本属性的能力。

我们将业务实体称为 Device、Location 和 Part；他们之间有关系。

设计 A：创建 DeviceAttribute、LocationAttribute 和 PartAttribute 表，每个表都有一个 ID、参考 ID（FK 到相应的表）、名称、值和类型。

设计 B：创建具有（ID、名称、值和类型列）和三个引用表的属性表 - 每个表保存从实体表之一到属性表 ID 之一的引用。

主要关注的是性能：
- 仅查询实体的数据时，3 个单独的 xxxAttribute 表会表现得更好，例如“给我设备 X 及其所有属性”，还是两种设计的性能相同？- 查询具有给定属性名称/值的实体时，1 属性表（设计 B）是否会表现得更好，例如“给我所有具有 Attribute.Name='GPS' 的实体”，或者是否等同于查询结合了设计 A 的 3 个表？- 在设计 B 的情况下：实体表（位置、设备、部件）上的更新是否会导致锁定其他实体表中的查询？

系统可能有数以万计的部件、数以千计的设备和数百个位置，并且可能必须以每秒数十到数百个查询的数量级进行处理。

通过将计划保存在文件中，我并不是要查看它，而是强制优化器使用保存的计划来执行某些查询。

例如，如果优化器选择对两表查询进行哈希连接，而我设法强制优化器使用嵌套循环连接，是否有任何方法可以保存嵌套循环连接计划并让优化器接下来使用它我执行相同查询的时间？

I've recently made a table to hold the language preferences of my users as follow:

CREATE TABLE [dbo].[systemUserLangPreference](
  [systemUserID] [int] NOT NULL,
  [langID] [int] NOT NULL,
  [preferredOrder] [int] NOT NULL,
  [createdBy] [int] NOT NULL,
  [createdOn] [datetime] NOT NULL,
  [lastActionBy] [int] NOT NULL,
  [lastActionOn] [datetime] NOT NULL,
CONSTRAINT [PK_systemUserLangPreference] PRIMARY KEY CLUSTERED 
([systemUserID] ASC, [langID] ASC)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
 ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
) ON [PRIMARY]

There's …

表的 CacheId 列存在自定义统计信息。隔夜统计更新后：

Statistics for INDEX 'ST_TableName_CacheId'.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Name                            Updated                         Rows                            Rows Sampled                    Steps                           Density                         Average Key Length              String Index                    
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ST_TableName_CacheId Apr 26 2014  2:04AM             121482                          121482                          6                               0                               4                               NO                                                              121482                          

All Density                     Average Length                  Columns                         
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0.1666667                       4                               CacheId                         

Histogram Steps                 
RANGE_HI_KEY                    RANGE_ROWS                      EQ_ROWS                         DISTINCT_RANGE_ROWS             AVG_RANGE_ROWS                  
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
39968                           0                               20247                           0                               1                               
40058                           0                               20247                           0                               1                               
40062                           0                               20247                           0                               1                               
40066                           0                               20247                           0                               1                               
40069                           0                               20247                           0                               1                               
41033                           0                               20247                           0                               1 …

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

我有一个数据库服务器，它的大小非常大，并且在非常小的服务器上运行，即。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 …