标签: sqlperformance

什么时候应该使用KEY,PRIMARY KEY,UNIQUE KEY和INDEX？

表现问题......

我有一个拥有地理定位数据(经度和纬度)的房屋数据库.

我想要做的是找到使用InnoDB数据库引擎将位置数据存储在我的MySQL(v5.0.24a)中的最佳方法,以便我可以执行大量查询,其中我将返回所有之间的所有主记录x1和x2 latitude以及y1和y2 longitude.

现在,我的数据库架构是

---------------------
Homes   
---------------------
geolat - Float (10,6)
geolng - Float (10,6)
---------------------

我的疑问是:

SELECT ... 
WHERE geolat BETWEEN x1 AND x2
AND geolng BETWEEN y1 AND y2

• 我上面描述的是使用Float(10,6)存储纬度和经度数据并分离出经度/纬度的最佳方法吗？如果不是,那是什么？存在Float,Decimal甚至Spatial作为数据类型.
• 这是从性能角度执行SQL的最佳方法吗？如果不是,那是什么？
• 使用不同的MySQL数据库引擎是否有意义？

更新:仍然没有答案

我在下面有3个不同的答案.一个人说要用Float.一个人说要使用INT.一个人说要使用Spatial.

所以我使用MySQL"EXPLAIN"语句来衡量SQL的执行速度.如果使用INT或FLOAT用于经度和纬度数据类型,似乎绝对没有SQL执行(结果集提取)的差异.

使用" BETWEEN"语句似乎比使用" >"或" <"SQL语句要快得多.使用" BETWEEN"比使用" >"和" <"语句快近3倍.

话虽如此,我仍然不知道如果使用Spatial会对性能产生什么影响,因为我不清楚它是否支持我运行的MySQL版本(v5.0.24)......以及我如何支持它如果支持.

任何帮助都会受到极大的欢迎

所以,最近DBA试图告诉我们我们不能使用的语法

SELECT X, Y, Z
INTO #MyTable
FROM YourTable

在我们的环境中创建临时表,因为该语法会在执行存储过程的持续时间内导致TempDB锁定.现在,我发现了一些详细说明临时表如何工作,执行范围,清理等的东西.但是对于我的生活,由于它们的使用,我没有看到任何关于阻挡的事情.

我们试图找到证据,证明我们不应该经历并为所有临时表执行CREATE TABLE #MyTable ...但是双方都无法找到证据.我正在寻找人们所拥有的任何见解.

附加信息

目前正在使用SQL Server 2005,很快将成为SQL Server 2008(企业版)

最近我在数据库中找到了几个没有定义聚簇索引的表.但是定义了非聚集索引,因此它们处于HEAP状态.

在分析中,我发现select语句对非聚集索引中定义的列使用过滤器.

这些表上没有聚簇索引会影响性能吗？

我在SQL Azure中有一个数据库,在15到30分钟之间做一个简单的操作:

select count(id) from mytable

数据库大约3.3GB,计数返回大约2,000,000,但我已经在本地尝试过,只需不到5秒!

我也运行了一个:

ALTER INDEX ALL ON mytable REBUILD

在数据库中的所有表上.

如果有人能指出我试图诊断/解决这个问题,我将不胜感激.

(请跳到下面的更新3,因为我现在认为这是问题,但我仍然不明白).

更新1:聚集索引扫描中99%的时间似乎如下图所示.我有

更新2:这就是我做的时候统计信息的回复:

SET STATISTICS IO ON
SET STATISTICS TIME ON
select count(id) from TABLE

统计:

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 317037 ms.

 SQL Server …

这个问题从这个问题开始,但现在似乎更恰当地问了,因为我意识到这是一个与DTU相关的问题.

基本上,运行:

select count(id) from mytable

编辑:添加where子句似乎没有帮助.

运行8到30 分钟(而SQL Server的本地副本上的相同查询大约需要4 秒).

下面是运行此查询时Azure门户中MONITOR选项卡的屏幕截图.注意我在没有触及数据库大约一周后做了这个,Azure报告我只使用了1%的DTU.

一些额外的东西:

• 在此特定测试中,查询运行时间为08:27.
• 当它运行时,上面的图表实际上显示DTU线在一段时间内处于100%.
• 数据库配置标准服务层,具有S1性能级别.
• 数据库大约是3.3GB,这是最大的表(计数返回大约2,000,000).

我很欣赏它可能只是我有限的理解,但如果有人能够澄清这是否真的是预期的行为(即一个简单的计数需要这么长时间才能运行并最大化我的DTU),我将非常感激.

摘要:由于性能和可维护性问题,我已经看到很多反对在MS SQL 中使用SELECT*的建议.然而,这些帖子很多都很老 - 5到10年!它似乎是,许多这些职位的,其性能的担忧可能实际上已经相当小,甚至在自己的时间,并作为可维护性关注("哦,不,如果有人改变了列,并且被索引获取数据一个数组!你的SELECT*会让你遇到麻烦!"),现代编码实践和ORM(如Dapper)似乎 - 至少在我的经验中 - 消除了这些问题.

所以:SELECT*是否存在今天仍然存在的问题？

更大的背景:我已经开始在一个有很多旧MS代码(ASP脚本等)的地方工作,但我一直在帮助实现大量现代化,但是:我的大部分SQL经验实际上来自于MySQL和PHP框架和ORM - 这是我第一次使用MS SQL - 我知道两者之间存在细微差别.另外:我的同事比我年长一点,并且有一些担忧 - 对我来说 - 似乎"老了".("可空的字段很慢!避免它们!")但是又一次:在这个特定的领域,他们肯定比我有更多的经验.

出于这个原因,我还想问一下:现代ORM中的SELECT*是否安全无瑕,是否有安全和明智的做法,是否有最新的在线资源表明这样？

谢谢!:)

我有一个presto集群配置了12个工作程序,Java应用程序正在查询它们.群集能够执行30个并发请求(如果有更多,则它们排队).

应用程序可能会发送大约80-100个不同的查询,我希望这些查询由集群处理.

问题:当按顺序执行查询时,它们的完成速度明显快于并行执行查询时的速度.

例如,如果我按顺序运行100个查询,则每个查询需要1-12秒才能完成,并且它们都会在大约2分钟内完成.但如果我并行启动所有这些,则需要大约8-12分钟才能完成所有这些操作.在拐角处,最多需要30分钟.

如果我查看presto控制台,我发现大多数查询被阻止,只有1-3个实际上处于Running状态.

不幸的是我无法发布任何查询.它们通常访问不同的模式(一个查询中最多6个),它们充满了连接和嵌套查询.同时,大多数都是按照最佳实践编写的.

问题:如何提高性能？至少我应该调查哪些方面来找出根本原因？

以下是一个最慢查询的指标(可能是数字会对您说些什么).

Resource Utilization Summary

CPU Time            8.42m
Scheduled Time      26.04m
Blocked Time        4.77d
Input Rows          298M
Input Data          9.94GB
Raw Input Rows      323M
Raw Input Data      4.34GB
Peak Memory         10.18GB
Memory Pool         reserved
Cumulative Memory   181G seconds

Timeline

Parallelism         477
Scheduled Time/s    1.47K
Input Rows/s        281K
Input Bytes/s       9.60MB
Memory Utilization  0B

我有一张书桌:

CREATE TABLE `books` (
    `id` INT(11) NOT NULL AUTO_INCREMENT,
    `nameOfBook` VARCHAR(32),
    `releaseDate` DATETIME NULL DEFAULT NULL,
    PRIMARY KEY (`id`),
    INDEX `Index 2` (`releaseDate`, `id`)
)
COLLATE='latin1_swedish_ci'
ENGINE=InnoDB

AUTO_INCREMENT = 33029692;

我将两个SQL请求与releaseDate上的sort进行了比较.这两个请求都返回相同的结果.

(简单的一个)

select SQL_NO_CACHE  id,name, releaseDate  
from books  
where releaseDate <= '2016-11-07'  
AND (releaseDate<'2016-11-07' OR id <    3338191)  
ORDER  by releaseDate DESC, id DESC limit 50;

和

(元组比较或行比较)

select SQL_NO_CACHE  id,name, releaseDate 
from books 
where (releaseDate ,id) < ('2016-11-07',3338191) 
ORDER  by releaseDate DESC, id DESC limit 50;

当我解释请求时,我得到了这个

简单的一个: …

给出下一个 SQL 语句：

Select * 
  from A join B
           on A.id1=B.id1 and 
              A.id2=B.id2
 where A.year=2016
   and B.year=2016

并且知道 tableA比 table 小得多B，所以我需要数据库首先按A年份访问表，然后加入，然后按B年份过滤表，我的问题是：

为提高性能而创建索引是否有意义B？(id1,id2,year)

非常感谢！