从数据库读取HTML数据很慢？需要更好的方法吗？
我们在mysql中有一个18GB的表，其中有一列“html_view”存储HTML源数据，我们正在页面上显示这些数据，但现在从“html_view”列获取html数据花费了太多时间，这使得页面加载缓慢。
我们想要一种可以简化现有结构的方法，以便更快地从数据库或任何其他方式加载 html 数据。
我们计划的一个想法是将 HTML 数据存储在 .txt 文件中，在 db 中我们将只存储 txt 文件的路径，并通过读取文件从该特定文件中获取数据。但我们担心它会在我们的服务器上进行大量的读写操作，从而可能会减慢服务器的速度。
有没有更好的方法可以让这种情况更快？
We have a table in mysql of 18GB which has a column "html_view" which stores HTML source data, which we are displaying on the page, but now its taking too much time to fetch html data from "html_view" column, which making the page load slow.
We want an approach which can simplify our existing structure to load the html data faster from db or from any other way.
One idea which we are planning is to store HTML data in .txt files and in db we'll just store path of the txt file and will fetch the data from that particular file by reading file. But we fear that it will make extensive read write operations n our server and may slowdown the server then.
Is there any better approach, for making this situation faster?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，为什么要在数据库中存储 HTML？为什么不按需渲染呢？
对于大文本表，您可以将压缩文本存储在字节数组中，或者以纯文本形式以 Base64 进行压缩和编码。
当您有一个包含大文本列的数组时，该表还有多少其他列？如果不是太多，您可以对表进行分区并创建一个两列键值存储。这应该比从磁盘读取文件更快、更简单。
First of all, why store HTML in database? Why not render it on demand?
For big text tables, you could store compressed text in a byte array, or compressed and encoded in base64 as plain text.
When you have an array with large text column, how many other columns does the table have? If it's not too many, you could partition the table and create a two column key-value store. That should be faster and simpler than reading files from disk.
请查看 Apache 缓存指南。
它解释了磁盘和内存缓存 - 从我的观点来看，如果内容是静态的（如数据库表所示），您应该使用 Apache 功能，而不是编写自己的较慢机制，因为您在顶部添加了多个层。
不过，通常的测量方法（而不是估计方法）仍然适用;-)。
Have a look at the Apache Caching guide.
It explains disk and memory caching - from my pov if the content is static (as the databae table indicates), you should use Apaches capabilities instead of writing your own slower mechanisms because you add multiple layers on top.
The usual measure instead of estimating does still apply though ;-).