标签: optimization

我想知道通过OPTIMIZE TABLE tbl_name在 MySQL 服务器中运行查询可以获得哪些好处[真正实用] 。

我检查了一次，发现运行后，下一次 DB 命中需要很长时间，可能是因为片段的重定位左右，但随后的命中显示了某种性能，我不确定查询缓存是否执行此技巧单独使用优化或优化就可以做到这一点。

如果可能的话，任何人都可以指导我一些实际的性能差异值，以便我可以进一步研究，因为在我们的项目中使用 MySQL 越来越重要。

例如，假设我有一张桌子：

Business(BusinessID, Lattitude, Longitude)

当然，所有的都被索引了。还有100万条记录

例如，假设我想找到最接近 106,5 的商家，我该怎么做？

如果我做

SELECT *
FROM Business
WHERE (Some formula to compute distance here) < 2000

例如，或者如果我这样做

SELECT *
FROM Business
TOP 20

理论上，计算机必须计算所有业务的距离，而实际上只有经度和纬度在一定范围内的业务才需要计算。

那么我怎样才能在 PhP 或 SQL 中做我想做的事呢？

我很感激到目前为止的答案。我正在使用 mysql 并且他们没有比明显的解决方案更有效的方法。MySQL 空间也没有计算距离函数。

我正在优化我们的数据库。本质上，我试图在我们的数据库中找到写入次数最多和读取次数最多的表。之后，我将把这些表符号链接到单独的驱动器中。

有没有办法跟踪每个表的活动？如下所示，每个表的 IOPS、写入、读取？

查询 1：

select distinct email from mybigtable where account_id=345

需要 0.1 秒

查询 2：

Select count(*) as total from mybigtable where account_id=123 and email IN (<include all from above result>)

需要 0.2 秒

查询 3：

Select count(*) as total from mybigtable where account_id=123 and email IN (select distinct email from mybigtable where account_id=345)

需要 22 分钟，其中 90% 处于“准备”状态。为什么要花这么多时间。

表是 innodb，在 MySQL 5.0 上有 320 万行

免责声明：请原谅我对数据库内部知识的缺乏。它是这样的：

我们运行一个应用程序（不是我们编写的），它在数据库的定期清理作业中存在很大的性能问题。查询如下所示：

delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in (
       select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY
       where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1");

直截了当、易于阅读和标准 SQL。但不幸的是非常慢。解释查询显示VARIABLE_SUBSTITUTION.BUILDRESULTSUMMARY_ID未使用现有索引：

mysql> explain delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in (
    ->        select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY
    ->        where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1");
| id | select_type        | table                 | type            | possible_keys                    | key     | key_len | ref  | rows    | Extra       |
+----+--------------------+-----------------------+-----------------+----------------------------------+---------+---------+------+---------+-------------+
|  1 | PRIMARY            | VARIABLE_SUBSTITUTION | ALL             | NULL                             | NULL    | NULL    | NULL | 7300039 …

使用 Microsoft SQL Server 2012 (SP3) (KB3072779) - 11.0.6020.0 (X64)。

给定一个表和索引：

create table [User].[Session] 
(
  SessionId int identity(1, 1) not null primary key
  CreatedUtc datetime2(7) not null default sysutcdatetime())
)

create nonclustered index [IX_User_Session_CreatedUtc]
on [User].[Session]([CreatedUtc]) include (SessionId)

以下每个查询的实际行数为 310 万，估计行数显示为注释。

当这些查询在 View 中提供另一个查询时，由于 1 行估计，优化器选择循环连接。 如何在此基础级别改进估计以避免覆盖父查询连接提示或求助于 SP？

使用硬编码日期效果很好：

 select distinct SessionId from [User].Session -- 2.9M (great)
  where CreatedUtc > '04/08/2015'  -- but hardcoded

这些等效查询与视图兼容，但都估计为 1 行：

select distinct SessionId from [User].Session -- 1
 where CreatedUtc …

我正在使用 Postgres 9.5。我有一个记录来自多个网站的页面点击量的表格。该表包含从 2016 年 1 月 1 日到 2016 年 6 月 30 日的大约 3200 万行。

CREATE TABLE event_pg (
   timestamp_        timestamp without time zone NOT NULL,
   person_id         character(24),
   location_host     varchar(256),
   location_path     varchar(256),
   location_query    varchar(256),
   location_fragment varchar(256)
);

我正在尝试调整一个查询，该查询计算执行给定页面命中序列的人数。该查询旨在回答诸如“有多少人查看了主页，然后访问了帮助站点，然后查看了感谢页面”之类的问题？结果看起来像这样

?????????????????????????????????????????
?  home-page ? help site  ? thankyou    ?
?????????????????????????????????????????
? 10000      ? 9800       ?1500         ?
?????????????????????????????????????????

请注意数字正在减少，这是有道理的，因为查看主页的 10000 人 9800 继续访问了帮助站点，而其中 1500 人继续点击了感谢页面。

3 步序列的 SQL 使用横向连接，如下所示：

SELECT 
  sum(view_homepage) AS view_homepage,
  sum(use_help) AS use_help,
  sum(thank_you) AS thank_you
FROM ( …

我有一个简单的SELECT声明。

USE [AdventureWorks2014]
GO

SELECT *
FROM Sales.SalesOrderDetail sod

执行计划有两个Compute Scalar.

为什么是这样？我原以为只得到Index Scan或者Table Scan?

第一个（最右边的）有

 [[AdventureWorks2014].[Sales].[SalesOrderDetail].LineTotal] = Scalar Operator(isnull(CONVERT_IMPLICIT(numeric(19,4),[AdventureWorks2014].[Sales].[SalesOrderDetail].[UnitPrice] as [sod].[UnitPrice],0)*((1.0)-CONVERT_IMPLICIT(numeric(19,4),[AdventureWorks2014].[Sales].[SalesOrderDetail].[UnitPriceDiscount] as [sod].[UnitPriceDiscount],0))*CONVERT_IMPLICIT(numeric(5,0),[AdventureWorks2014].[Sales].[SalesOrderDetail].[OrderQty] as [sod].[OrderQty],0),(0.000000)))

当第二个有：

[[sod].LineTotal] = Scalar Operator([AdventureWorks2014].[Sales].[SalesOrderDetail].[LineTotal] as [sod].[LineTotal])

考虑这个由N自连接组成的查询：

select
    t1.*
from [Table] as t1
join [Table] as t2 on
    t1.Id = t2.Id
-- ...
join [Table] as tN on
    t1.Id = tN.Id

它生成一个执行计划，其中包含 N 次聚集索引扫描和 N-1 次合并连接。

老实说，我看不出有任何理由不优化所有连接并仅执行一次聚集索引扫描，即将原始查询优化为：

select
    t1.*
from [Table] as t1

问题

• 为什么连接没有被优化掉？
• 说每个连接都不会改变结果集在数学上是不正确的吗？

测试：

• 源服务器版本：SQL Server 2014 (12.0.4213)
• 源数据库引擎版：Microsoft SQL Server 标准版
• 源数据库引擎类型：独立 SQL Server
• 兼容级别：SQL Server 2008 (100)

查询没有意义；它刚刚出现在我的脑海中，我现在对它很好奇。

这是表创建和 3 个查询的小提琴：使用inner join's、使用left join's 和混合。您也可以在那里查看执行计划。

似乎left join在结果执行计划中消除了inner joins而s 则没有。不过还是不明白为什么 …

“SQL 最终子树成本”和“查询时间性能”之间的一般关系是什么？

示例：当优化查询并且它从子树成本 0.2 到 0.1 时，这是否意味着查询时间将快两倍？我在查询中没有看到这种情况。

我们有一个服务器，即使使用“设置统计时间”和“DBCC DROPCLEANBUFFERS”也无法真正衡量查询性能。服务器、事务、程序、后台项目中有不同的进程在进行。

谢谢，