标签: query-optimization

我有一些查询导致我们的实时环境超时.(> 30秒)

如果我运行探查器并获取正在运行的SQL并从Management Studio运行它,那么它们需要很长时间才能运行第一次,然后在每次运行后降至几百毫秒.

这显然是SQL缓存数据并将其全部存储在内存中.

我确信可以对SQL进行优化,使其运行得更快.

我的问题是,如何在第二次运行时"修复"这些查询数据已经被缓存并且速度很快？

我有一个MySQL表:

CREATE TABLE mytable (
     id INT NOT NULL AUTO_INCREMENT,
     other_id INT NOT NULL,
     expiration_datetime DATETIME,
     score INT,
     PRIMARY KEY (id)
) 

我需要以下列形式运行查询:

SELECT * FROM mytable
WHERE other_id=1 AND expiration_datetime > NOW() 
ORDER BY score LIMIT 10

如果我将此索引添加到mytable:

CREATE INDEX order_by_index
ON mytable ( other_id, expiration_datetime, score);

MySQL能否order_by_index在上面的查询中使用整个？

现在看来似乎应该是可以的,但后来根据MySQL的文档:" 该指数还可以用来即使ORDER BY不索引完全一致,只要所有索引的未使用部分和所有的额外ORDER BY列是WHERE子句中的常量. "

上面的段落似乎表明索引只能用于常量查询,而我的是范围查询.

任何人都可以澄清在这种情况下是否会使用索引？如果没有,我可以用任何方式强制使用索引吗？

谢谢.

SQL 2008.
我有一个测试表:

create table Sale
(
    SaleId int identity(1, 1)
        constraint PK_Sale primary key,
    Test1 varchar(10) null,
    RowVersion rowversion not null
        constraint UQ_Sale_RowVersion unique
)

我用10k测试行填充它.

declare @RowCount int = 10000
while(@RowCount > 0)
begin
    insert Sale default values
    set @RowCount -= 1
end

我运行这两个查询:

-- Query #1

select *
from Sale
where RowVersion > 0x000000000001C310

-- Query #2

declare @LastVersion rowversion = 0x000000000001C310

select *
from Sale
where RowVersion > @LastVersion

我无法弄清楚为什么这两个查询有不同的执行计划.
查询#1对UQ_Sale_RowVersion索引执行索引查找.
查询#2对PK_Sale进行索引扫描.

我想查询#2做索引搜索.
我将不胜感激.
谢谢.

[编辑] …

为什么选择它,称之为A,(0.02406s):

select * from char_kills
where rid_first <= 110 and rid_last >= 110
order by kills desc
limit 500;

比排序顺序慢10倍,称之为B,(0.00229s):

select * from char_kills
where rid_first <= 110 and rid_last >= 110
order by kills
limit 500;

你怎么能优化A？在MySQL 5.5上使用InnoDB表.

更多信息如下.

describe char_kills;

cid, int(10) unsigned, NO, PRI, , 
rid_first, int(10) unsigned, NO, PRI, , 
rid_last, int(10) unsigned, NO, PRI, , 
kills, int(11), NO, PRI, , 
offi_rank, smallint(5) unsigned, YES, , , 

select count(*) from char_kills;

146312 …

这很奇怪.我正在尝试在MySQL中使用Views(对于具有Sybase和SQL Server的更多经验,我是MySQL的新手).无论如何,这个新项目我们都在使用MySQL,因为它似乎具有良好的性能.然而,为了简化Web前端的查询,我们决定创建一些视图,一切都运行良好,但它们需要永远运行.

视图非常简单,只是select语句(这些表中确实有几百万行).比如说这个查询:

SELECT CAST(classifier_results.msgDate as DATE) AS mdate
       ,classifier_results.objClass AS objClass
       ,COUNT(classifier_results.objClass) AS obj
       ,classifier_results.subjClass AS subjClass
       ,COUNT(classifier_results.subjClass) AS subj 
FROM classifier_results 
WHERE (classifier_results.msgDate >= (curdate() - 20)) 
GROUP BY 
  CAST(classifier_results.msgDate as DATE)
  ,classifier_results.objClass
  ,classifier_results.subjClass 
ORDER BY classifier_results.msgDate DESC

以正常方式运行时,大约需要1.5秒才能返回结果.

但是,当此查询被放入视图(按原样)时 - 即

CREATE VIEW  V1a_sentiment_AI_current AS    
SELECT CAST(classifier_results.msgDate as DATE) AS mdate
       ,classifier_results.objClass AS objClass
       ,COUNT(classifier_results.objClass) AS obj
       ,classifier_results.subjClass AS subjClass
       ,COUNT(classifier_results.subjClass) AS subj 
FROM classifier_results 
WHERE (classifier_results.msgDate >= (curdate() - 20)) 
GROUP BY 
  CAST(classifier_results.msgDate as …

我有这张桌子(500,000排)

CREATE TABLE IF NOT EXISTS `listings` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `type` tinyint(1) NOT NULL DEFAULT '1',
  `hash` char(32) NOT NULL,
  `source_id` int(10) unsigned NOT NULL,
  `link` varchar(255) NOT NULL,
  `short_link` varchar(255) NOT NULL,
  `cat_id` mediumint(5) NOT NULL,
  `title` mediumtext NOT NULL,
  `description` mediumtext,
  `content` mediumtext,
  `images` mediumtext,
  `videos` mediumtext,
  `views` int(10) unsigned NOT NULL,
  `comments` int(11) DEFAULT '0',
  `comments_update` int(11) NOT NULL DEFAULT '0',
  `editor_id` int(11) NOT NULL DEFAULT '0',
  `auther_name` varchar(255) DEFAULT NULL,
  `createdby_id` int(10) …

采取以下两个表:

Table "public.contacts"
       Column       |            Type             |                       Modifiers                       | Storage  | Stats target | Description
--------------------+-----------------------------+-------------------------------------------------------+----------+--------------+-------------
 id                 | integer                     | not null default nextval('contacts_id_seq'::regclass) | plain    |              |
 created_at         | timestamp without time zone | not null                                              | plain    |              |
 updated_at         | timestamp without time zone | not null                                              | plain    |              |
 external_id        | integer                     |                                                       | plain    |              |
 email_address      | character varying           |                                                       | extended |              |
 first_name         | character varying           |                                                       | extended |              | …

We have noticed some inconsistencies in our MySQL performance for query times that we feel cannot be explained by just server load. Some queries seem to be much efficient than others, despite having a similar setup.

Edit: Since opening this question, our database crashed (for unknown reasons at this moment, RDS teams are investigating), and after a reboot the issue is no longer reproducible and the queries are the same speed. I still would like to know what was wrong …

我一直在阅读许多SQL书籍和文章中,选择性是创建索引的重要因素.如果色谱柱的选择性较低,则索引搜索会带来更大的危害.但这些文章都没有解释原因.任何人都可以解释为什么会这样,或提供相关文章的链接？

我有以下代码(注意includes和.each):

subscribers = []
mailgroup.mailgroup_members.opted_to_receive_email.includes(:roster_contact, :roster_info).each { |m|
  subscribers << { :EmailAddress => m.roster_contact.member_email,
                   :Name => m.roster_contact.member_name,
                   :CustomFields => [ { :Key => 'gender', 
                                        :Value => m.roster_info.gender.present? ? m.roster_info.gender : 'X' 
                                    } ] 
                  } if m.roster_contact.member_email.present?
}
subscribers

相应地,我在日志中看到以下内容(即select * from ROSTER_INFO ... IN (...)):

SELECT `ROSTER_INFO`.* FROM `ROSTER_INFO` WHERE `ROSTER_INFO`.`ID` IN ('1450', '1000', '1111')

然而,紧接着之前的查询列表中select * from ROSTER_INFO已经指定了每个ID IN:

RosterInfo Load (84.8ms)  SELECT `ROSTER_INFO`.* FROM `ROSTER_INFO` WHERE `ROSTER_INFO`.`ID` = '1450' …