标签: performance

我有一个负载很重的 LAMP 系统，每秒处理大约 40 个请求，每秒执行大约 300 个 MySQL 查询。这是 MySQLAdmin 状态的输出：

Uptime: 5051  Threads: 1  Questions: 1418500  Slow queries: 0  Opens: 456  
Flush tables: 1  Open tables: 450  Queries per second avg: 280.835

但是，全局状态显示大约 5-10% 的表锁争用。

所以，我想弄清楚需要更长时间的查询。

是否可以将慢查询日志设置为小于一秒？对于我的查询，即使是 100 毫秒的执行时间也很长。

对于以下 SELECT 查询，是否可以避免“使用临时”和“使用文件排序”？我想不出办法做到这一点。

我尝试为 top_expire 和 program 添加索引，但没有帮助 ORDER BY 查询需要 1 秒以上，而没有它在 localhost 上仅为 0.003 秒

询问

SELECT ad.*, p.link
    FROM (SELECT ad.*
        FROM mod_ad ad 
        JOIN mod_ad_auta auta ON ad.id = auta.ad_id
        WHERE ad.active != 0 AND ad.usr_active != 0 AND ad.expire > 1371151608  AND ad.cat_id = '1' AND ad.price <= '10000' 
          AND auta.rocnik BETWEEN '1950' AND '2013' 
          AND auta.km BETWEEN '0' AND '500000'
        ORDER BY top_expire DESC, program DESC,  ad.id DESC  LIMIT 0,10) as ad
JOIN pages …

在考虑数据库性能时，VLF 有多重要？什么会描述 VLF 的最佳情况？

我有两个表，第一个表包含 CMS 中的所有文章/博客文章。其中一些文章也可能出现在杂志中，在这种情况下，它们与包含杂志特定信息的另一个表具有外键关系。

这是这两个表的 create table 语法的简化版本，其中删除了一些非必要的行：

CREATE TABLE `base_article` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `date_published` datetime DEFAULT NULL,
  `title` varchar(255) NOT NULL,
  `description` text,
  `content` longtext,
  `is_published` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `base_article_date_published` (`date_published`),
  KEY `base_article_is_published` (`is_published`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE `mag_article` (
    `basearticle_ptr_id` int(11) NOT NULL,
    `issue_slug` varchar(8) DEFAULT NULL,
    `rubric` varchar(75) DEFAULT NULL,
    PRIMARY KEY (`basearticle_ptr_id`),
    KEY `mag_article_issue_slug` (`issue_slug`),
    CONSTRAINT `basearticle_ptr_id_refs_id` FOREIGN KEY (`basearticle_ptr_id`) REFERENCES `base_article` (`id`)
) ENGINE=InnoDB DEFAULT …

表T_PIN有 300,000 个引脚和T_POLYGON36,000 个多边形。T_PIN有这个索引：

CREATE SPATIAL INDEX [T_PIN_COORD] ON [dbo].[T_PIN]
(
[Coord]
)USING  GEOGRAPHY_GRID 
WITH (GRIDS =(LEVEL_1 = HIGH,LEVEL_2 = HIGH,LEVEL_3 = HIGH,LEVEL_4 = HIGH), 
CELLS_PER_OBJECT = 128, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, 
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
ON [PRIMARY];

T_POLYGON 已：

CREATE SPATIAL INDEX [T_POLYGON_COORD] ON [dbo].[T_POLYGON]
(
[COORD]
)USING  GEOGRAPHY_GRID 
WITH (GRIDS =(LEVEL_1 = HIGH,LEVEL_2 = HIGH,LEVEL_3 = HIGH,LEVEL_4 = HIGH), …

有人可以帮我比较这些查询并解释为什么 PostgreSQL 查询的执行时间不到 2000 毫秒，而 MongoDB 聚合查询需要将近 9000 毫秒，有时甚至高达 130K 毫秒吗？

PostgreSQL 9.3.2 on x86_64-apple-darwin, compiled by i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00), 64-bit

PostgreSQL 查询

SELECT locomotive_id,
   SUM(date_trunc('second', datetime) - date_trunc('second', prevDatetime)) AS utilization_time

FROM bpkdmp 
WHERE datetime >= '2013-7-26 00:00:00.0000' 
AND   datetime <= '2013-7-26 23:59:59.9999'
GROUP BY locomotive_id
order by locomotive_id

MongoDB 查询

db.bpkdmp.aggregate([
   {
      $match : {
          datetime : { $gte : new Date(2013,6,26, 0, 0, 0, 0), $lt : new …

我们有什么（软件）：

• 带有基本配置的PostrgeSQL 9.3（在 中没有变化postgresql.conf）
• 视窗 7 64 位