将 GZIP:ed 文本存储在 mysql 中？
对于较大的应用程序和数据库来说，在将文本数据插入数据库之前对其进行 GZIP 压缩是很常见的事情吗？
我猜想在再次解压缩之前，对实际文本字段的任何全文搜索都将不起作用？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
对于较大的应用程序和数据库来说，在将文本数据插入数据库之前对其进行 GZIP 压缩是很常见的事情吗？
我猜想在再次解压缩之前，对实际文本字段的任何全文搜索都将不起作用？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（3）
我还没有看到太多这样的事情，因为它基本上阻止了人们对 MySQL 端的数据进行任何操作：
like，没有=，没有其他操作...不过，如果您仅使用数据库来存储该数据，而不是操作它，那么它可能会很有趣。
注意：您可能需要进行一些基准测试，以衡量这可能产生的性能影响，因为压缩/解压缩需要 CPU！
之后的问题是：您会在客户端（PHP）端还是在服务器（MySQL）端处理压缩？
在第二种情况下，有一个
COMPRESS()函数，由 MySQL 提供，您可能会感兴趣。I've not seen this done much, as it basically prevents one from doing any manipulation on the data on the MySQL-side :
like, no=, no other manipulation...Still, if you're using your database only to store that data, and not manipulate it, it might be interesting.
Note : you might want to do a few benchmarks, to measure the performance-impact this could have, as compression/decompression requires CPU !
After that, question is : will you deal with the compression on the client (PHP) side, or on the server (MySQL) side ?
In the second case, there is a
COMPRESS()function, provided by MySQL, that might interest you.如果您在 MySQL 中使用最新版本之一的 InnoDB 表类型，则可以启用 对 InnoDB 表本身进行压缩。
它在较低级别进行管理，因此不会更改您的查询或任何内容。根据我的阅读，压缩的轻微开销可以通过减少磁盘 IO 并允许将更多数据存储在内存缓冲池中来抵消。然而，您确实提到了 InnoDB 不支持的全文搜索，因此这可能不是一个选项。
MySQL 中还有一个 Archive 表类型，但你会丢失索引我相信除了主键之外的功能。
另一种选择是“打包”MyISAM 表，但我相信这会使表只读并且不会像其他选项那样压缩。
If you are using the InnoDB table type in MySQL with one of the more recent versions then it's possible to enable compression on an InnoDB table itself.
It's managed at the low level so doesn't change your queries or anything. From what i've read, the slight overhead for compression is offset by reducing disk IO and allowing more data to be stored in the buffer pool in memory. You did however mention full-text search which InnoDB doesn't support, so this may not be an option.
There is also an Archive table type in MySQL but you lose indexing functionality apart from the primary key i believe.
Another alternative is to "pack" a MyISAM table but i believe that makes the table read only and doesn't compress as well as the other options.
坏主意。当磁盘空间小于 1 GB 时，为节省一些空间而进行的额外处理不会抵消执行此操作所需的额外编程时间（不仅仅是最初，请记住维护）。
这可能会使数据库访问速度变慢，因为数据需要解压缩/压缩。索引无法在压缩数据上正常运行，因为您需要进行表扫描、解压缩数据，然后进行比较。全文搜索也已推出。
如果您必须这样做，请不要使用 gzip。使用内置的 COMPRESS 函数。
Bad idea. Extra processing to save some space when disk space is less than $1 GB won't offset the extra programming time to do this (not just initially, remember maintenance).
This will likely make database accesses slower since the data needs to be decompressed/compressed. Indexes wont function properly on compressed data since you would need to do a table scan, decompress the data, then compare. And full text search is out as well.
If you must do this, please don't use gzip. use the built in COMPRESS function.