哪些表受到 Magento 中目录 URL 重写索引的影响?
非常简单的问题,哪些表受到 Magento 中目录 URL 重写索引的影响?
每次我运行此索引时,都需要很长时间才能运行,并且索引的管理状态会卡在“正在处理”上。
我尝试使用 SHOW FULL PROCESSLIST 查找锁表,并且 core_url_rewrite 被截断,现在我正在等待重建再次运行,同时监听 system.log 中的错误。
很高兴确切地知道使用了哪些表,以及它是否只是 core_url_rewrite 和 Catalogsearch_fulltext,我也已截断它们......
刚刚找到这些文件:
magento/var/locks/index_process_1.lock magento/var/locks/index_process_2.lock magento/var/locks/index_process_3.lock magento/var/locks/index_process_4.lock magento/var/locks/index_process_5.lock magento/var/locks/index_process_6.lock magento/var/locks/index_process_7.lock magento/var/locks/index_process_8.lock magento/var/locks/index_process_9.lock magento/var/locks/index_process_10.lock
它们似乎与我尝试运行索引的时间匹配,但是它们是否像 mysql 锁定文件那样停止索引创建?
Pretty straightforward question, which tables are affected by the Catalog URL Rewrites index in Magento?
Each time I run this index it takes a long time to run and the admin status for the index gets stuck on PROCESSING.
I have tried to find lock tables with SHOW FULL PROCESSLIST and have TRUNCATED core_url_rewrite and now I am waiting for the rebuild to run again, while I listen for error in system.log.
It would be nice to know exactly which tables are used and if it is just core_url_rewrite and catalogsearch_fulltext, which I have also truncated....
Just found these files:
magento/var/locks/index_process_1.lock
magento/var/locks/index_process_2.lock
magento/var/locks/index_process_3.lock
magento/var/locks/index_process_4.lock
magento/var/locks/index_process_5.lock
magento/var/locks/index_process_6.lock
magento/var/locks/index_process_7.lock
magento/var/locks/index_process_8.lock
magento/var/locks/index_process_9.lock
magento/var/locks/index_process_10.lock
They seem to match times when I tried to run the index, but do they stop the index creation like a mysql lock file would do?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
问题不在于流程做了什么,而在于流程如何做。它会将产品一件一件地装载并进行处理。尝试在您的 magento/shell 目录中运行
php indexer.php --reindex Catalog_url
。当 max_execution 时间设置为零并且有足够的内存时,它最终会完成。
只要锁定文件存在,其他重新索引进程就无法启动。关于表的问题有点复杂,尝试打开mysql常规日志并观察更新。 MySQL 中花费的时间并不是一个大问题,实例化产品对象既慢又容易泄漏。确保您有此补丁 。
It's not about what the process does, it's about how it does it. It will load up products one by one and do processing. Try to run
php indexer.php --reindex catalog_url
in your magento/shell directory. With a max_execution time set to zero and enough memory, it will eventually finish.
As long as the lock file is there, no other reindex process can start. The question about tables is a little more complex, try to turn mysql general log and watch for updates. The time spent in MySQL is not a big concern, instantiating product objects is both slow and leaky. Make sure you have this patch.