Questions tagged «performance»

到处搜寻有关VARCHAR2Oracle 的列大小是否影响性能的报告似乎不一。 我想VARCHAR稍微谈谈大小问题，并希望对此有所了解： 给定要存储在（Oracle）数据库中的（多行）自由文本字段（不是名称之类的简短内容），在没有达到最大VARCHAR容量（VARCHAR2(4000)在Oracle上）的情况下（在性能或其他方面）有什么意义（选择Oracle）较小的值，例如1024或512，因为无论如何在98％的情况下，这可能就足够了。

18 oracle  performance  varchar 

在阅读了慢速SQL查询之后，不确定如何优化，这让我开始思考查询的一般性能。当然，我们需要将第一个表（在连接其他表时）的结果尽可能小，然后再进行连接（此问题的内部连接），以使我们的查询快一点。 示例，应该这样： SELECT * FROM ( SELECT * FROM table1 WHERE col = @val ) t INNER JOIN table2 ON col = col2 比以下更好/更快： SELECT * FROM table1 INNER JOIN table2 ON col = col2 WHERE table1.col = @val 我的理论如下（这可能不是正确的实现，我试图从我读过的一本SQL Server 2008内部书籍（MSFT Press）中记住）： 查询处理器首先获取左表（表1） 在过滤掉必要的行之前，连接第二个表（表2）并形成笛卡尔积（如果适用） 然后使用SEELCT语句最后执行WHERE，ORDER BY，GROUP BY，HAVING子句。 因此，如果在上面的语句1中表较小，则在形成笛卡尔积时SQL引擎要做的工作较少。然后，当您到达where语句时，您将得到减少的结果集，可以从中筛选出结果集。 我可能还差得远，这是不真实的。就像我说的，这是一种理论。 …

18 sql-server  performance  join 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 2年前关闭。 在更新行时，许多ORM工具都会发出UPDATE语句来设置与该特定实体相关联的每一列。 优点是您可以轻松批处理update语句，因为UPDATE无论您更改什么实体属性，该语句都是相同的。此外，您甚至还可以使用服务器端和客户端语句缓存。 因此，如果我加载一个实体并仅设置一个属性： Post post = entityManager.find(Post.class, 1L); post.setScore(12); 所有列都将被更改： UPDATE post SET score = 12, title = 'High-Performance Java Persistence' WHERE id = 1 现在，假设我们在title属性上也有一个索引，DB难道不应该意识到该值没有改变吗？ 在本文中，Markus Winand说： 所有列上的更新都显示了我们在上一节中已经观察到的相同模式：响应时间随每个其他索引的增加而增加。 我不知道为什么会产生这种开销，因为数据库将相关的数据页从磁盘加载到内存中，从而可以确定是否需要更改列值。 即使对于索引，它也不会重新平衡任何内容，因为对于未更改的列，索引值不会更改，但是它们已包含在UPDATE中。 是否也需要导航与冗余未更改列关联的B +树索引，只是为了让数据库意识到叶值仍然相同？ 当然，某些ORM工具允许您仅更新已更改的属性： UPDATE post SET score = 12, WHERE id = 1 但是，当为不同的行更改不同的属性时，这种类型的UPDATE可能并不总是从批量更新或语句缓存中受益。

17 performance  index  update  orm 

我有一个带有默认值为NULL的参数的SP，然后我想执行以下查询： SELECT ... FROM ... WHERE a.Blah = @Blah AND (a.VersionId = @VersionId OR (@VersionId IS NULL AND a.VersionId IS NULL)); 在WHERE上述检查两个非空值和一个NULL值@VersionId。 就性能而言，最好改用一条IF语句并将查询复制到一个搜索非NULL的查询中，而将另一个复制为NULL的查询，这样会更好吗？： IF @VersionId IS NULL BEGIN SELECT ... FROM ... WHERE a.Blah = @Blah AND a.VersionId IS NULL; ELSE BEGIN SELECT ... FROM ... WHERE a.Blah = @Blah …

17 sql-server-2008  performance 

这两个示例查询之间是否存在性能差异？ 查询1： select count(*) from table1 a join table2 b on b.key_col=a.key_col where b.tag = 'Y' 查询2; select count(*) from table1 a join table2 b on b.key_col=a.key_col and b.tag = 'Y' 注意唯一的区别是补充条件的位置。第一个使用WHERE子句，第二个将条件添加到ON子句。 当我在Teradata系统上运行这些查询时，说明计划是相同的，并且JOIN步骤显示了每种情况下的附加条件。但是，在有关MySQL的SO问题上，答案之一是建议使用第二种样式，因为WHERE处理是在进行联接之后进行的。 对这样的查询进行编码时，是否要遵循一般规则？我猜它必须是平台相关的，因为它显然对我的数据库没有影响，但这也许只是Teradata的功能。而且，如果它是依赖于平台的，我非常希望获得一些文档参考；我真的不知道该找什么。

17 mysql  oracle  performance 

我想在我的MySQL数据库中存储一些几何位置。为此，我使用了POINT数据类型。我几乎到处都读到该函数GeomFromText应用于在表中插入数据。 但是，我发现这POINT(X,Y)也可行。我没有找到任何说明为什么GeomFromText应代替POINT。 例如，我有以下简单关系： CREATE TABLE Site ( SiteID BIGINT UNSIGNED, Position POINT ); 我可以使用以下两个变体插入值： INSERT INTO Site ( 1, GeomFromText( 'POINT(48.19976 16.45572)' ) ); INSERT INTO Site ( 2, POINT(48.19976, 16.45572) ); 当查看表格（SELECT * FROM Site）时，会看到该位置的相同二进制二进制对象，而查看坐标（SELECT *, AsText(Position) FROM Site）时，也会看到相同的值。 那么为什么要使用GeomFromText？这两个变体之间是否存在（已知的）性能差异？在MySQL以外的其他数据库系统中如何解决？

17 mysql  performance  spatial 

由于RAM的限制，是否有可能使InnoDB使用与MyISAM相同的索引而不是聚集索引，同时又可以利用其并发性能？

17 mysql  performance  index  innodb  myisam 

有哪些有效的方法可以对数据库操作执行程序性能测试，尤其是在数据库本身不提供专用工具的环境中？ 例如，在Google App Engine中，整个页面加载被评估为一项操作，其中可能包括特定的数据库操作。SQLite和其他集成DB中也可能出现此问题。由于很难完全抽象出需要测试的（等效）选择和插入内容，是否有推荐的数据库工具对这些类型的查询执行更彻底的诊断？

17 performance  database-design  google-app-engine  performance-testing 

以为通过以下链接可以解决此问题-解决方法可以正常工作-但补丁程序没有解决。与Microsoft支持人员一起解决。 http://support.microsoft.com/kb/2606883 好的，所以我有一个问题想扔给StackOverflow看看是否有人有想法。 请注意这是与SQL Server 2008 R2 问题：启用触发器后，从具有15000条记录的表中删除3000条记录需要3-4分钟，而禁用触发器则仅需要3-5秒。 表格设定 我们将两个表称为Main和Secondary。辅助数据库包含我要删除的项目的记录，因此在执行删除时，我会加入到辅助数据库表。进程在delete语句之前运行，以用要删除的记录填充辅助表。 删除声明： DELETE FROM MAIN WHERE ID IN ( SELECT Secondary.ValueInt1 FROM Secondary WHERE SECONDARY.GUID = '9FFD2C8DD3864EA7B78DA22B2ED572D7' ); 该表有很多列和大约14个不同的NC索引。在确定引发问题的原因之前，我尝试了多种尝试。 打开页面锁定（默认情况下我们已关闭） 手动收集统计数据 禁用自动收集统计信息 验证索引的健康状况和碎片 从表中删除聚簇索引 检查执行计划（没有显示为丢失的索引，对于实际删除，成本为70％，对于记录的合并/合并，成本约为28％ 扳机 该表具有3个触发器（每个触发器分别用于插入，更新和删除操作）。我修改了删除触发器的代码以使其返回，然后选择一个以查看触发了多少次。在整个操作过程中，它仅触发一次（如预期）。 ALTER TRIGGER [dbo].[TR_MAIN_RD] ON [dbo].[MAIN] AFTER DELETE AS SELECT 1 RETURN 回顾 启用触发器-语句需要3-4分钟才能完成 关闭触发器-语句需要3-5秒才能完成 …

17 sql-server  performance  sql-server-2008-r2  trigger  delete 

如果我想用创建5GB数据库 CREATE DATABASE [test] CONTAINMENT = NONE ON PRIMARY ( NAME = N'test', FILENAME = N'E:\2012\test.mdf' , SIZE = 5529600KB , FILEGROWTH = 1024KB ) LOG ON ( NAME = N'test_log', FILENAME = N'E:\2012\test_log.ldf' , SIZE = 1024KB , FILEGROWTH = 10%) 我的SSD 需要1分钟。 但是当我将SQL Server用户添加到 Perform volume maintenance tasks …

17 sql-server  performance 

我碰到这个问题最近，无法在网上找到的任何讨论。 下面的查询 DECLARE @S VARCHAR(1) = ''; WITH T AS (SELECT name + @S AS name2, * FROM master..spt_values) SELECT * FROM T T1 INNER JOIN T T2 ON T1.name2 = T2.name2; 始终获得嵌套循环计划 尝试通过INNER HASH JOIN或INNER MERGE JOIN提示强制问题会产生以下错误。 由于此查询中定义的提示，查询处理器无法生成查询计划。重新提交查询而不指定任何提示，也无需使用SET FORCEPLAN。 我发现了一种允许使用散列或合并联接的解决方法-将变量包装在一个聚合中。生成的计划的成本大大降低（19.2025比0.261987） DECLARE @S2 VARCHAR(1) = ''; WITH T AS (SELECT …

16 sql-server  performance  query-optimization 

在查看需要花费很长时间才能执行的存储过程的列表时，最引人注目的是它。但是，大多数等待时间（81％）是ASYNC_NETWORK_IO，我知道原因：存储过程传输大约400 MB的信息。 在文档中，它指出ASYNC_NETWORK_IO的原因是客户端无法跟上大量数据的流传，这可能是事实。我不确定如何使客户端保持同步，因为它所做的只是通过ADO.NET调用存储过程，然后仅处理数据集。 因此，鉴于此信息，我是否应该担心此过程的ASYNC_NETWORK_IO等待类型？它实际上对服务器性能有影响吗？ 其他信息： 我正在使用SQL Server 2005的Service Pack 2。 客户端应用程序与SQL Server位于同一盒子上（我知道，我知道...但是我对此无能为力）。

16 sql-server  performance  sql-server-2005  stored-procedures  wait-types 

在我妻子的工作中，关于仅对存储过程中的临时表中的varchar(255)所有varchar字段使用都存在争议。基本上，一个营地希望使用255，因为即使定义更改，它也将始终有效，而另一个营地则希望坚持使用源表中的大小以提高性能。 表演营对吗？还有其他含义吗？他们正在使用SQL Server。

16 sql-server  performance  datatypes  temporary-tables 

我很难找到有关如何在PostgreSQL中缓存索引的“一般性”解释，因此我希望对以下任何或所有假设进行现实检查： PostgreSQL索引（如行）位于磁盘上，但可以缓存。 索引可能完全在高速缓存中，或者根本不存在。 是否缓存它取决于使用频率（由查询计划者定义）。 因此，大多数“明智的”索引将一直存在于缓存中。 索引buffer cache与行位于同一高速缓存（？）中，因此索引所使用的高速缓存空间不可用于行。 我理解这一点的动机来自另一个问题，我曾问过有人建议在不能访问大多数数据的表上使用部分索引。 在进行此操作之前，我想弄清楚使用部分索引有两个优点： 我们减小了缓存中索引的大小，从而为缓存中的行本身释放了更多空间。 我们减小了B树的大小，从而加快了查询响应速度。

16 postgresql  performance  index-tuning  cache 

我有以下表和索引定义： CREATE TABLE munkalap ( munkalap_id serial PRIMARY KEY, ... ); CREATE TABLE munkalap_lepes ( munkalap_lepes_id serial PRIMARY KEY, munkalap_id integer REFERENCES munkalap (munkalap_id), ... ); CREATE INDEX idx_munkalap_lepes_munkalap_id ON munkalap_lepes (munkalap_id); 为什么在以下查询中不使用munkalap_id上的索引？ EXPLAIN ANALYZE SELECT ml.* FROM munkalap m JOIN munkalap_lepes ml USING (munkalap_id); QUERY PLAN Hash Join (cost=119.17..2050.88 …

16 postgresql  performance  index  join  primary-key