我有一个很大的“用户”表，只有偶尔需要大多数列（用户配置文件），而有些列（用户凭据）经常需要。我不喜欢用配置文件获取整行只是为了显示用户的名字。
将表分成两部分，即。用户和配置文件的性能更好，或更糟（必须对配置文件进行两次查询）？ MySql在获取只有几列的行之间是否存在性能差异？比如说一百个？
谢谢。
我应该提到我在Laravel框架上。我将不得不使用Raw查询来选择列。我不喜欢这个主意，但我会调查一下。
答案 0 :(得分：1)
SQL开发中有一个古老的习惯用法，它指出当你实际做SELECT *时，你真的不希望表中的一切。
您可以采取一些措施来加快查询速度并提高效果：
1）仅选择SQL语句所需的字段，例如：
SELECT `username`, `password`, `email` FROM `users` WHERE `id` = 1
2）向表中添加索引，以便可以优化经常使用的任何查询。例如，如果您定期查找用户的电子邮件地址，则可以考虑在email列中添加索引。
您可能还想查看MySQL Partitioning，但我认为这不是您真正需要的。 MySQL被设计为一个拥有数百万条记录的数据库。
您还应该记住，在设计数据库时，至少要执行Normal Forms Normalization的前三个{{3}}至关重要。这可确保数据完整性，还可优化项目的数据库结构。
答案 1 :(得分：0)
答案 2 :(得分：0)
我有一个很大的“用户”表
定义'大'。
在表上定义适当的索引应该是微不足道的，这样所有访问都是命令log（n）（其中n是行数），而在没有索引的情况下，访问是O（n） 。这意味着在dex中缺少套接字时检索行的努力（以及因此花费的时间）与行数一起线性增加 - 但是随着索引，它随着行数的对数而增加。还需要考虑许多其他因素来获取检索行所需的实际时间 - 添加更多表会增加成本，但通常第一个加速访问的调用端口是添加适合查询的索引（或索引）应用于数据。这意味着要查看解释计划以及表格和索引结构。
当数据库必须读取然后丢弃磁盘中的数据时（对于全表扫描或无效索引），它仍然将内容存储在内存中 - 替换可能有用的数据 - 在某些情况下，全表扫描可以是最有效的解决方案 - 但有效地刷新I / O缓存的大部分。在没有覆盖索引的情况下，必须将计划匹配的每一行的整个读入内存。通常这是一个昂贵的位 - 但是通过对这样的表使用'SELECT *'，你可以保证不会有覆盖索引，并且在客户端传输和保存数据还有进一步的成本。
接下来，考虑数据的变化频率。如果你有可变长度列（varchar，CLOB等），那么对行的更新可能会导致新版本大于旧版本 - 导致行链接/迁移：单个记录的数据可以进一步扩展磁盘导致检索行所需的更多搜索。
因此，如果在检查到您拥有非常有效的索引之后，仍然需要提高性能，那么将表中的列拆分为2个或更多新表可能会带来优势。
将行拆分到单个数据库实例上的单独表中不太可能显着提高性能（但是，如果您有多个数据库，或者有时有多个磁盘，这是一个可行的策略。）
您没有提供表/索引的结构，也没有提供查询的解释计划 - 因此无法就如何提高性能提出明确的建议。即使有这些信息，也无法替代尝试不同的模型并测量整个系统的性能。