【问题标题】:Optimize the query "Select * from tableA"优化查询“Select * from tableA”
【发布时间】:2012-06-25 17:28:47
【问题描述】:

我在一次采访中被问到如果执行需要大量时间,可以使用哪些方法来优化查询 Select * from TableA。 (TableA) 可以是任何具有大量数据的表。面试官没有给我任何选择,例如选择几列或使用“WHERE”子句,而是希望我为主题查询提供解决方案。

【问题讨论】:

  • 你有想过面试官说的话吗?
  • 索引、过滤器和键哦,天哪!
  • 在某些时候我想他可能是在嘲笑我,我无法得出任何解决方案,这就是我在这里的原因。
  • 很难知道他在寻找什么。他可能是相对缺乏经验和期望的答案,例如“列出所有列而不是 *,因为这样更快”或“添加 ORDER BY,因为这总是会加快速度”。有经验的人可能正在寻找的东西是:检查查询计划,看看是否有计算列或其他类似的东西占用额外的资源;重新审视需求——用户真的需要以任意顺序排列整个表格吗?表上是否有聚集索引;如果没有,是否充满了转发指针?
  • 这似乎是一个糟糕的、真正开放式的问题,因为有太多不切实际的答案完全取决于你不知道的实际情况;答案如向服务器添加内存以增加缓存、安装更快的网卡、使用分页查询(跳过/采取),因为它是用户感知的缓慢等等。

标签: sql-server tsql query-optimization


【解决方案1】:

很难知道面试官在寻找什么。

他们可能是相对缺乏经验和预期的答案,例如:

  • "列出所有列而不是 *,因为这样更快!";或者,
  • “添加 ORDER BY,因为这样总能加快速度!”

有经验的人可能会寻找的东西是:

  • 检查查询计划,是否有计算列或其他类似的东西占用额外的资源?
  • 重新审视需求 - 用户真的需要以任意顺序排列整个表格吗?
  • 表上是否有聚集索引;如果不是,堆中是否充满了转发指针?
  • 基础表(和/或用于满足查询的索引)上是否存在过多碎片?
  • 查询是否被阻止?
  • 查询在等待什么?
  • 查询是否在等待外部资源(例如糟糕的 I/O 子系统、内存授予、tempdb 自动增长)?
  • 查询是并行的,并且由于统计信息过期而遭受数据包等待吗?

有很多潜在的因素可能使查询变慢可能使该查询成为一个糟糕的选择。

【讨论】:

  • 谢谢 Aaron,您对这个问题提供了更深入的了解。正如您所强调的那样,问题似乎不合适,因为存在潜在的机制,这可能会使此查询运行缓慢。
【解决方案2】:

实际上,一些数据库将具有优化命令,这些命令将重建数据库表以减少碎片 - 这种方式实际上提高了此类查询的性能。

PostgreSQL 和 SQLite 都有命令

VACUUM;

MySQL 和 ORACLE 有一个命令

OPTIMIZE TABLE table;

它很昂贵,因为它会移动大量数据。但是这样做会使页面更加平衡,并且这种方式通常会缩小数据库的总大小(但有些数据库可能会决定在此时添加索引,因此它也可能会增长)。

由于数据存储在页面中,通过重建数据库减少页面数量可以提高性能,即使是SELECT * FROM table; 语句。

【讨论】:

    猜你喜欢
    • 2022-12-07
    • 2012-08-14
    • 2011-12-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-10-18
    • 2011-12-22
    相关资源
    最近更新 更多