标签: query-optimization

我一直在使用我的MySQL数据库的索引,而现在却从不正常了解到他们.通常我会在我要搜索的任何字段上放置索引或使用WHERE子句进行选择,但有时它看起来不是那么黑白.

MySQL索引的最佳实践是什么？

示例情况/困境:

如果一个表有六列并且所有这些列都是可搜索的,那么我应该将它们全部索引还是不索引？

.

索引的负面性能影响是什么？

.

如果我有一个VARCHAR 2500列可以从我的网站的部分搜索,我应该索引吗？

阅读一些SQL Tuning文档我发现了这个:

Select count(*):
- 计算行数
- 通常不正确地用于验证记录的存在

是否Select count(*)真的如此糟糕？

验证记录存在的正确方法是什么？

JOIN查询比几个查询更快吗？(您运行主查询,然后根据主查询的结果运行许多其他SELECT)

我问,因为加入它们会使我的应用程序的设计变得复杂

如果它们更快,那么任何人都可以近似粗略估计多少？如果它是1.5倍我不在乎,但如果它是10倍我想我做.

引用文档:

创建索引时,与键关联的数字指定索引的方向,因此它应始终为1(升序)或-1(降序).方向对于单个键索引或随机访问检索无关紧要,但如果您对复合索引进行排序或范围查询,则该方法很重要.

但是,我认为没有理由为什么指数的方向应该对复合指数起作用.有人可以提供进一步的解释(或示例)吗？

关于LIKE查询数据库中特定表的响应时间,我看到了相当大的变化.有时我会在200-400毫秒内得到结果(非常可接受),但有时候返回结果可能需要30秒.

我知道LIKE查询是非常耗费资源的,但我只是不明白为什么响应时间会有这么大的差异.我已经在该owner1字段上构建了一个btree索引,但我认为这对LIKE查询没有帮助.有人有主意吗？

示例SQL:

SELECT gid, owner1 FORM parcels
WHERE owner1 ILIKE '%someones name%' LIMIT 10

我也尝试过:

SELECT gid, owner1 FROM parcels
WHERE lower(owner1) LIKE lower('%someones name%') LIMIT 10

和:

SELECT gid, owner1 FROM parcels
WHERE lower(owner1) LIKE lower('someones name%') LIMIT 10

有类似的结果.
表行数:约95,000.

我正在处理Postgres表(称为"生命"),其中包含time_stamp,usr_id,transaction_id和lives_remaining列的记录.我需要一个查询,它将为每个usr_id提供最新的lives_remaining总数

1. 有多个用户(不同的usr_id)
   
2. time_stamp不是唯一标识符:有时用户事件(表中逐行)将以相同的time_stamp发生.
   
3. trans_id仅在非常小的时间范围内是唯一的:随着时间的推移它会重复
   
4. remaining_lives(对于给定用户)可以随时间增加或减少

例:

time_stamp|lives_remaining|usr_id|trans_id
-----------------------------------------
  07:00  |       1       |   1  |   1    
  09:00  |       4       |   2  |   2    
  10:00  |       2       |   3  |   3    
  10:00  |       1       |   2  |   4    
  11:00  |       4       |   1  |   5    
  11:00  |       3       |   1  |   6    
  13:00  |       3       |   3  |   1    

因为我需要使用每个给定的usr_id的最新数据来访问该行的其他列,所以我需要一个给出如下结果的查询:

time_stamp|lives_remaining|usr_id|trans_id
-----------------------------------------
  11:00  |       3       |   1  |   6    
  10:00  |       1       |   2  |   4    
  13:00  |       3       |   3  | …

我有一张桌子:

col1 | col2 | col3
-----+------+-------
1    | a    | 5
5    | d    | 3
3    | k    | 7
6    | o    | 2
2    | 0    | 8

如果用户搜索"1",程序将查看col1具有"1"的程序,然后它将获得col3"5"中的值,然后程序将继续搜索"5",col1并且将获得"3" in col3等等.所以它会打印出来:

1   | a   | 5
5   | d   | 3
3   | k   | 7

如果用户搜索"6",它将打印出来:

6   | o   | 2
2   | 0   | 8

如何构建SELECT查询来做到这一点？

我有一个索引(自动增量)和整数值的表.该表长达数百万行.

如何最有效地搜索表格的最后n行中是否出现某个数字？

我有这个跨数据库查询...

SELECT
            `DM_Server`.`Jobs`.*,
            `DM_Server`.servers.Description AS server,
            digital_inventory.params,
            products.products_id,
            products.products_pdfupload,
            customers.customers_firstname,
            customers.customers_lastname
        FROM `DM_Server`.`Jobs`
        INNER JOIN `DM_Server`.servers ON servers.ServerID = Jobs.Jobs_ServerID
        JOIN `cpod_live`.`digital_inventory` ON digital_inventory.jobname = Jobs.Jobs_Name
        JOIN `cpod_live`.`products` ON products.products_pdfupload = CONCAT(digital_inventory.jobname, ".pdf")
        JOIN `cpod_live`.`customers` ON customers.customers_id = products.cID
        ORDER BY `DM_Server`.`Jobs`.Jobs_StartTime DESC LIMIT 50

它运行良好,直到我做它们LEFT JOIN.我认为通过不指定一种类型的连接,它被认为是一种LEFT JOIN.这不是这种情况吗？

我有一个包含数百个笨拙命名表的数据库(CG001T,GH066L等),我对每个人都有"友好"名称的观点(例如,"CUSTOMERS"视图是"SELECT*FROM GG120T") .我想在我的视图中添加"WITH SCHEMABINDING",以便我可以获得与之相关的一些优点,例如能够索引视图,因为少数视图已经计算了动态计算成本昂贵的列.

SCHEMABINDING这些观点是否存在缺点？我发现一些文章含糊地暗示了缺点,但从未详细介绍过它们.我知道一旦视图是模式绑定的,你就不能在没有先删除视图的情况下改变任何会影响视图的内容(例如,列数据类型或排序规则),所以这是一个,但除此之外？似乎索引视图本身的能力远远超过了更仔细地规划模式修改的缺点.