No two rows is not right and might be part of the problem. Remove one of the rows – doesn’t matter which as long as for the one you leave the meta_type column is set to ‘topic_cache’ and the meta_key column is set to ‘new’.
And on the second question then yes – that is the data needing removal.
Yes – as soon as you said two then it all fell into place.
You should still remove the redundant one. This will now be the one where the data you removed has stayed removed. The other will have repopulated.
So at some point a second cache record was created but, because we only expect one, the old one that was no longer being updated was being queried but oddly I bet the newer one was the one being updated.
The important question, of course, is why there were two. That is something I will have to look into to see if I can fathom a way that might come about.
I would remove one – doesn’t matter which. And then also make sure the other has that empty column again. Let it start clean.
Yellow Swordfish said
The important question, of course, is why there were two. That is something I will have to look into to see if I can fathom a way that might come about.
would the innodb conversion that I ran have any impact on that? Also I deleted 31, should I change the meta id of watches to 31 or just leave it 32?
alright, thank-you yellow, I just bit the bullet and delved into the scary world of my live database, happy to report it was a success and I did not totally destroy my site!
I wonder if the long query issue was because of the two different tables, it was trying to query them both
No that’s not the issue there. That actual data is used in the construction of the query not the execution.
But – as I said above somewhere – all the ‘long query’ thing is about is the physical text length of the query itself. Nothing to do with its execution or performance. As I also said – it seems 100% pointless and annoying to track something like that which has no relevance to anything!
