提高PHP网站速度:去掉mySQL VARCHAR-999字段,转成文本文件

问题描述 投票:0回答:1

我有一个 PHP+mySQL 网站,显示了 300,000 种产品的数据:名称、描述、如何修复、在哪里购买等

最初,mySQL表是这样设计的:

- product_id: MEDIUMINT
- category_id: SMALLINT
- weight_kg: SMALLINT
- height_cm: SMALLINT
- width_cm: SMALLINT
- depth_cm: SMALLINT
- name: VARCHAR(100)
- label: VARCHAR(100)
- short_description: VARCHAR(200)
- long_description: VARCHAR(9999)
- how_to_fix_it: VARCHAR(9999)
- where_to_buy_it: VARCHAR(9999)
- similar_products: VARCHAR(9999) <--- it stores "ACME 12|acme-12#ACME 555|acme-555" to link directly other products, avoiding to do subsequent queries to find the names and labels of the similar products.

我发现表的大小很大,主要是由于文本字段(VARCHAR-9999)的存在,这会减慢查询和网站速度。我认为这些 VARCHAR-9999 字段不必在表内,因为我不对它们执行 SQL 操作。我只在显示单个产品的信息时查询它们。

我正在考虑创建 300,000 个文本文件 (product_id.txt) 以供 PHP 读取,每个文件存储文本信息(每行一个字段):

long_description: blah blah
how_to_fix_it: blah blah
where_to_buy_it: blah blah
similar_products: blah blah

我每次显示单个产品的信息时,我都会PHP从磁盘读取文本文件,我认为这样会更快。

如果有任何处理此问题的类似经验,我将不胜感激。有没有什么聪明的方法来存储这 300,000 个文件?我在考虑 300 个子目录('000'、'001'、...、'299'),每个子目录存储 1,000 个文件,以便读取更快。

php mysql performance pagespeed txt
1个回答
0
投票

我发现表的大小很大,主要是因为文本字段(VARCHAR-9999)的存在

除非您将这些字符串填充到 9999 个字符,否则您的 VARCHAR(9999) 不会使用比 VARCHAR(256) 更多的空间来存储 34 个字符的字符串 'ACME 12|acme-12#ACME 555|acme-555'会用。那是 VAR 部分——它将可变长度的字符串存储在可变大小的空间中,但不会超过所需的空间。 9999 只允许更长的字符串,它不会为每个短字符串使用那么多空间。

您可以在 MySQL 客户端中使用

SHOW TABLE STATUS LIKE 'mytable'\G
验证平均行长度。这会根据表格中的页面样本报告估计的行数和平均行大小。这是近似值,但通常非常接近。我预测它会显示你的行没有你想象的那么大。

我会用 PHP 从磁盘读取文本文件,我认为这样会更快。

对于我所期望的典型查询,该解决方案不会更快。从磁盘读取文件比从 RAM 读取要慢几个数量级,并且 MySQL 会尽可能多地将数据库页面缓存在 RAM 中。它在这方面非常擅长,代表了数百名工程师多年的微调。我怀疑你有生之年能否做得更好(我不是在侮辱你,我不认为任何一个开发人员可以单独完成那么多工作)。

也就是说,它可能对于数据的某些特定用途(例如计算产品)更快。你没有描述任何查询,所以我们无法猜测你将如何使用这些数据。

任何优化策略都取决于 您将执行哪些 查询,因为每个优化策略都针对一种类型的查询进行优化,但代价是降低其他查询的最优性。

无论如何,实现自己的数据库并使其像RDBMS一样可靠和灵活是一个很好的学习经验。你会学到很多东西。

30万个文件有什么巧妙的存储方式吗?

是的......在数据库中! :-)

我在考虑 300 个子目录('000'、'001'、...、'299'),每个子目录存储 1,000 个文件,以便读取更快。

这取决于文件系统。有些有数十万个文件的大性能问题。我曾经实施过一个系统,将数千个文件整理到子目录层次结构中……那是在 1992 年,但我敢说文件系统从那时起就取得了进步!现代文件系统应该能够处理更多的文件。

把你的数据分成30万个文件不一定就赢了。如果您需要查询产品的平均尺寸怎么办?您必须打开 300,000 个文件并阅读所有文件。您是否测量过在您的操作系统上打开那么多文件描述符的开销?如果您需要执行查询,那么将它们全部存储在一个文件中不是更好吗?打开那么多文件太费时了?

你能在一个进程中打开那么多文件吗?例如,在 Linux 中,这受到操作系统上的 ulimit 设置的限制。你的 ulimit 值是多少?

这就是我所说的优化取决于您需要哪些查询。

© www.soinside.com 2019 - 2024. All rights reserved.