我在他们的数据库大小上看了少于繁忙的客户端

我得到以下内容:

+-----------------------------------------------+------------+
| Tables                                        | Size in MB |
+-----------------------------------------------+------------+
| catalog_product_index_price_cl                |    3057.00 |
| cataloginventory_stock_status_cl              |    1974.00 |
| catalogsearch_fulltext_cl                     |     101.64 |
| catalog_product_flat_cl                       |     100.64 |
| catalog_category_product_index_cl             |      37.58 |
| sales_flat_order_item                         |      29.34 |
| catalog_product_index_price                   |      16.58 |
| customer_entity_varchar                       |      14.09 |
| catalog_product_index_price_idx               |      12.06 |
| catalog_product_entity_varchar                |      10.58 |
| index_event                                   |      10.03 |
| customer_entity_int                           |       6.61 |
| catalog_product_entity_decimal                |       6.55 |
| catalog_product_entity_int                    |       5.45 |
| catalog_product_entity_datetime               |       5.36 |
| catalogsearch_fulltext                        |       4.80 |
| region_city                                   |       4.52 |
.

我发现有点令人震惊。为什么价格指数为3GB?这是dev数据库,我可以安全地缩小它吗?

有帮助吗?

解决方案

*_cl表是ChangeLog表。他们记录改变的产品,库存等的所有ID。

一个cronjob应该理论上更新索引(异步索引器),然后从表中删除条目。

许可以下: CC-BY-SA归因
scroll top