0

我实际上有一个有 30 列的表。一天之内，这张表可以得到大约 3000 条新记录！

列数据如下所示：

IMG                                        Name          Phone        etc..

http://www.site.com/images/image.jpg       John Smith    123456789    etc..
http://www.site.com/images/image.jpg       Smith John    987654321    etc..

我正在寻找一种优化表大小以及 sql 查询响应时间的方法。我正在考虑做类似的事情：

Column1

http://www.site.com/images/image.jpg|John Smith|123456789|etc..

然后通过php我将每个值存储到一个数组中..

会更快吗？

编辑

因此，以结构为例，假设我有两个表：

package
package_content

这是表的结构package：

id | user_id | package_name | date

这是表的结构package_content：

id | package_id | content_name | content_description | content_price | content_color | etc.. > 30columns

问题是对于每个包，我最多可以获得 16 行内容。例如 ：

id   | user_id | package_name | date
260    11        Package 260    2013-7-30 10:05:00

 id | package_id | content_name | content_description | content_price | content_color | etc.. > 30columns
1     260          Content 1      Content 1 desc        58              white           etc..
2     260          Content 2      Content 2 desc        75              black           etc..
3     260          Content 3      Content 3 desc        32              blue            etc..
etc...

然后用php我做这样

select * from package
while not EOF {
   show package name, date etc..
   select * from package_content where package_content.package_id = package.id and package.id = package_id
   while not EOF{
       show package_content name, desc, price, color etc...
   }
}
4

2 回答 2

1

会更快吗？当然不。如果您需要按 or 进行搜索，Name或者Phone您etc...必须Column1每次都提取这些值。您永远无法优化这些查询。

如果您想让表格更小，最好考虑将一些列拆分到另一个表格中。如果您想采用该选项，请发布整个结构。但请注意，列数对速度的影响不大。我的意思是它可以，但它在会让你慢下来的事情清单上。

最后，每天 3,000 行大约是每年 100 万行。如果数据库设计得相当好，MySQL 可以轻松处理。

附录：部分表结构加上示例查询和伪代码添加到问题。

伪代码显示了package一次查询所有表，然后一次package_content查询一个匹配的行。这是一种非常缓慢的处理方式；最好使用JOIN：

SELECT
  package.id,
  user_id,
  package_name,
  date,
  package_content.*
FROM package
INNER JOIN package_content on package.id = package_content.id
WHERE whatever
ORDER BY whatever

这将立即加快速度。

如果您在网页上显示，请务必使用WHERE子句限制结果 - 没有人会希望在单个网页上看到 1,000 或 3,000 或 1,000,000 个包 :)

最后，正如我之前提到的，列数对于查询优化来说并不是一个大问题，但是......

  1. 拥有一个非常宽的结果行意味着更多的数据必须通过从 MySQL 到 PHP 的线路，并且

  2. 您不可能在网页上显示 30 多列信息而不会看起来很糟糕，尤其是在您阅读大量行的情况下。

考虑到这一点，您最好package_content在查询中选择特定列，而不是使用SELECT *.

于 2013-07-30T17:57:50.533 回答
1

不要合并任何列，这没有用，最终可能会更慢。

您应该在查询的列上使用索引。我确实有一个包含大约 30 列的网站，其中 atm 大约有 600.000 个结果。如果您EXPLAIN在查询之前使用，您应该查看它是否使用任何索引。如果您在同一张表中有一个 JOIN 和 2 个值和一个 WHERE。您应该按照 JOIN -> WHERE 的顺序使用 3 列创建一个组合索引。如果您加入同一张表，您应该将其视为单独的索引。

例如：

SELECT p.name, p.id, c.name, c2.name 
FROM product p
JOIN category c ON p.cat_id=c.id
JOIN category c2 ON c.parent_id=c2.id AND name='Niels'
WHERE p.filterX='blaat'

您应该在类别中有一个组合索引

parent_id,name
AND
id (probably the AI)

产品索引

cat_id
filterX

使用这个简单的解决方案，您可以将查询从 NOT DOABLE 优化到 0.10 秒，甚至更快。

如果你使用 MySQL 5.6，你应该切换到 INNODB，因为 MySQL 在优化 JOINS 和子查询方面做得更好。MySQL 也会尝试将它们运行到 MEMORY 中，这将使其更快。请记住，备份 INNODB 表可能需要额外注意。

您可能还考虑制作 MEMORY 表以进行超快速查询（您仍然需要索引）。

您还可以通过使整数大小为 4（4 个字节，而不是 11 个字符）来进行优化。并不总是使用 VARCHAR 255。

于 2013-07-30T17:58:17.203 回答