我在这个自我页面中被告知不要在我的SQL查询中使用通配符*。
查询错误
SELECT * FROM table
而不是
SELECT field_a, field_b, field_c FROM table
我理解只有一个原因，如果您只需要知道该查询中的3个字段，那么sql引擎无法使用所有字段并将它们发送回您的程序，如果您只是想使用一些
但是，如果您需要检索所有（或几乎所有）字段数据，或者在这些情况下最好指定所有字段，这会让我怀疑使用它是否正确。
除了减少从数据库引擎发送到程序的数据量之外，还有其他原因可以避免使用通配符吗？
答案 0 :(得分：3)
你理解的原因是非常有效的，也许是这么说的最有力的理由。
在许多应用程序中，表包含太多列（比方说20），表大小也很大，包含数百万条记录，如果只想检索特定列，那么就没有必要使用通配符*那么MYSQL引擎必须不必要地迭代所有列和所有行。
但是要强调一点这并不意味着*不鼓励事实上，如果你有20列并且你想从中检索值，那么在同样的情况下它可以是一个福音所有栏目。
要添加更多内容，由于浮动原因，*可能会变慢：
在您的表中，您不会在所有列上创建索引，并且查询使用全表扫描。所以它使查询变慢。
如果要从包含可变长度列的表返回尾随字段，因此可能会导致轻微的搜索开销。
答案 1 :(得分：3)
使用*表示您正在查询所有表格的字段。如果那是你的应用程序应该做的，那么使用它是有意义的。
如果那不是你的应用假设那么做，那么这可能会给你带来麻烦。如果将来修改该表，最好的情况是您的应用程序将查询它不需要的列，这可能会损害性能。最糟糕的情况是它会破裂。
答案 2 :(得分：1)
我同意所有其他人认为它本身并不“邪恶”，但我确实试图避免它，因为我遵循的具体设计模式。通常在设计表之后，我会创建视图并将相关表连接在一起。最后，我创建了存储过程，然后从视图中进行选择。
我发现在视图和存储过程中使用通配符是有问题的（至少在SQL Server中）。一开始看起来一切都很好，但是在将新字段添加到源表后它会崩溃。它破坏了视图，然后必须重建才能修复。根据系统的大小，这可能是一个问题。
由于视图中的通配符选择会在更改源表后导致损坏的视图，因此我已开始避免使用通配符，并在向表中添加新列后手动更改视图。
答案 3 :(得分：0)
除了以下两个之外没有这样的具体原因，这两个原因也被认为是编写查询的有效且优化的方法。
使用字段名称可让我们更自由地使用字段和输出
但是对于通配符没有这样的限制或不好，如果你需要所有字段，请使用它们。