问题标签 [database-optimization]

我正在制作一个留言板，并尝试检索常规主题（即未粘贴的主题）并按最后发布消息的日期对它们进行排序。我能够做到这一点，但是当我有大约 10,000 条消息和 1500 个主题时，查询时间> 60 秒。

我的问题是，我可以对查询做些什么来提高性能，还是我的设计存在根本缺陷？

这是我正在使用的查询。

编辑这里是解释计划

索引

我想知道，就带宽和整体效率而言，哪个选项最昂贵。

假设Client我的应用程序中有一个类，数据库中有一个表client。

Client.getById拥有一个检索整个客户记录的静态函数还是拥有多个检索单个字段Client.getNameById的静态函数更好？Client.getMobileNumberById

如果一条记录有很多字段，而我最终在当前脚本中使用了一个或两个字段，那么检索所有内容并在应用程序内部决定如何处理所有数据是否更好？

顺便说一句，我正在使用PHP和MySQL。

请您帮助我如何将其包含 INDEXES在我的表格中，我已经在几个教程中阅读过它，但仍然无法在我的数据库中实现它。为了提高我的数据库的效率：我已经安装php_apc.dll在 wampserver 上，它更快一点，我也尽量避免 SELECT * 在我的查询中使用。但如何实施 INDEX是我的问题。如果你能指出哪里需要的话，我会很高兴的INDEX。

这是我的数据库架构

我的大部分查询都围绕 INSERTINTO MAINTABLE， STUDENTS.....然后 是SELECTFROMMAINTABLE和 STUDENTSCOURSES

感谢您的耐心和时间。我最欣赏它。谢谢。

**查询示例"

请原谅我的格式。我用手机打字。感谢您的时间。

为什么有人会通过执行以下操作将实体（例如user）分配到多个表中：

你从这个数据库设计中得到什么加速奖励吗？这是非常违反直觉的，因为看起来执行链连接来检索数据听起来比使用选择投影要糟糕得多。

当然，如果只使用 user_id 和 username 来执行其他查询，那是一种加速，但值得吗？那么，真正的优势在哪里，以及适合这种数据库设计策略的兼容工作场景是什么？

后期编辑：在这篇文章的细节中，请假设一个完整的、唯一的实体，其属性在数量上没有变化（例如，汽车只有一种颜色，而不是两种，用户只有一个用户名/社交 sec 编号/入学编号/home address/email/etc.. 也就是说，我们处理的不是一对多关系，而是一对一、完全一致的实体描述。在上面的示例中，就是这种情况其中单个表已被“拆分”为与其拥有的非主键列一样多的表。

我正在构建一个速度至关重要的预测拨号器。为了拨打这个号码，我从表格中提取客户信息并构建呼叫文件以供 pbx 采取行动。

目前，我为每个区号都有一个表格，我们一次拨打一个区号，但我们正在切换到一个模型，在该模型中，我们根据跨越多个邮政编码的领土进行拨号。一些区号存在于多个邮政编码中。每个表每月都会添加新号码，并通过与数百万个号码的请勿呼叫列表进行比较来清理。

所以我的问题是，我应该如何最有效地组织这些数据？

一张大表似乎适得其反，因为我们正在谈论数百万条已清理数据的记录。

我目前的推理是维护区号表以进行导入和清理，然后将清理后的记录复制到地区表中，通过在地区代码表中搜索该地区的邮政编码来创建。

我目前通过一个 auto_incremented INT 主键、一个唯一的电话号码和一个跟踪已被呼叫的号码的状态来索引这些表，或者在请勿呼叫列表中。在构建通话文件时，我将记录标记为排队，然后根据通话完成后的方式进行标记，因此对于每个通话，都会进行一次搜索和两次更新。

搜索在区域代码表中查找特定状态。更新基于记录 ID。

问题的核心是：按邮政编码组织并按状态搜索会更快，还是按区号组织它们并按状态和邮政编码搜索？或者每次我们建立一个从区号表构建的区域时，最好的办法是创建一个新表？

如果这似乎是一个愚蠢的问题，请原谅我，我一直在自学 SQL，因为我一直在构建它，并且数据库设计和性能的细微差别有点超出我的技能范围。

表的总大小为 200 万行并且还在增长。

我有一个counts表，其中包含类似于（大约 14 个计数列）的列：

每当用户添加照片或朋友时，此表就会更新。

我将使用 InnoDB 引擎，因为最好有行锁定，但与此同时，该表上的读取次数也很多。对于每个用户，当他们看到其他用户的个人资料时，甚至用户侧菜单都包含所有这些计数。

哪个引擎最适合大多数这样的写入和读取？

首先，我应该指出我对 SQL Server 索引了解不多。

我的情况是我有一个 SQL Server 2008 数据库表，它有一个 varchar(max) 列，通常填充很多文本。

我的 ASP.NET Web 应用程序有一个搜索工具，可以查询此列以进行关键字搜索，并且根据搜索的关键字的数量，它们可能是 SQL 查询中的一个或多个LIKE '%keyword%'语句来进行搜索。

我的 Web 应用程序还允许按此表中的各种其他列进行搜索，而不仅仅是那一列。还有一些来自其他表的连接。

我的问题是，是否值得在此列上创建索引以提高这些搜索查询的性能？如果是这样，什么类型的索引，仅索引一列就足够了，还是我需要包括其他列，例如主键和其他可搜索列？

我知道就效率而言，最好有一个大查询而不是许多小查询，因为最好将与数据库的连接数量减少到最低限度（尤其是在网络流量密集的情况下）。

所以我的问题是，除了隔离和原子化一组数据库操作（如果其中一个操作失败则进行回滚）之外，事务是否像一个大查询？我的意思是，如果你需要做很多数据库操作，你能把它包装在一个事务中，然后把它变成一个单一的大操作吗？

我们有表格Site并且Content在我们的数据库中。

每个站点由不同的客户运营，每个站点都有自己的内容。

在网站的前端，我们提供了一个搜索框，它在内容表上使用全文/自由文本搜索来返回结果，但每个网站只能从其自身返回结果，而不是从数据库中的其他网站返回结果。

SQL Server 查询优化器在这里表现不佳。如果它针对内容很少的站点优化查询，那么对于内容很多导致超时的站点，查询的执行会非常糟糕。

我们知道我们可以添加OPTION(RECOMPILE)到查询的末尾来解决这个问题，但我的问题是......

为每个站点创建一个缓存表，以便可以定期缓存每个站点的内容并让搜索存储过程查找缓存表而不是使用参数会更好吗？

仅在添加/更改内容时才会更新/刷新缓存。

我的想法是，这将......

a) 减少被搜索表的大小，只包含正确站点的记录

b) 允许全文搜索为每个站点生成更准确的内容索引

c) 允许查询优化器独立缓存每个站点的优化查询

它是否正确？我这样做对吗？

晚上，

我正在经历将数据从 15 岁的只读数据格式导入 MySQL 的漫长过程，以从中构建一些较小的统计表。

我之前构建的最大表（我认为）是 3200 万行，但我没想到它会变得那么大，而且真的让 MySQL 吃力。

该表将如下所示：

所以，小整数和varchars。

任何人都可以提供有关如何使其尽快发挥作用的建议吗？任何列上的索引会有所帮助，还是它们只会减慢查询速度。

每列中的大部分数据将被重复多次。有些字段的可能值不超过 100 个。

我将查询表的主要列是：surname、name、rco、rplace。