There is a bug that remains open in the WordPress Core tracking system that impacts Store Locator Plus database tables. The bug will degrade database performance after each consecutive update to the Store Locator Plus base plugin. The problem and resolution are described below.
There is a glitch in a core WordPress function, dbDelta(), that creates duplicate table indexes. Store Locator Plus uses 3 indexes on the locations table. Indexes significantly increase the performance of database searches when used properly. For Store Locator Plus an index exists on the store name, the latitude, and the longitude. The latter two mean that whenever someone does a location search on your website the data returned from the locations table is found much more quickly than if the data index was not in place. On large installs, those with hundreds or thousands of locations, the difference is notable.
To put the index and any other data table elements in place, SLP uses the built-in dbDelta function from WordPress. This is the recommended method for managing table and index creation as well as structure updates. It works great. Most of the time.
The problem is that dbDelta() has a glitch that creates a new index every time the Store Locator Plus version changes. It should be looking for the store, lat, and long indexes and if not there it will create them. Instead if it finds an existing index it creates a new index and adds a numeric suffix. After a number of upgrades to SLP you end up with a database that has multiple indexes like this:
Those _# indexes are IDENTICAL to the non-suffixed version.
This is bad. Any time a record is updated or added in the locations table it is MUCH slower as every index needs to be updated. After just 3 updates MySQL is performing 9 index updates on every record operation versus 3.
It can also confuse and SLOW DOWN record searches as the MySQL engine will take longer to determine which is the best index to use as it has to load the entire index directory. I assume MySQL is smart enough to drop after the “first perfect match”, but that is purely conjecture. If that is true the search impact would be minimal. If MySQL is not that intelligent and it looks at ALL INDEXES before selecting the “best match” during a search the impact here can be notable as well, though not nearly as dramatic as a updating or inserting new data.
Do You Have A Problem?
Unfortunately there are only 2 ways to tell.
First – your WordPress site starts throwing errors (usually hidden in the error log) that are coming from MySQL and tell you your index limit of 64 entries has been exceeded. You shouldn’t need to increase this limit, it is per-table and there are very few (if any) cases where 64 indexes on a single table is helpful.
The Manual Fix
The way to fix installations by hand is to use the MySQL command line tool, or PHPMyAdmin and drop the _# indexes from the wp_store_locator table. Since Store Locator Plus is not the only plugin affected you may want to check for any other tables that are created by plugins and see if they suffer from the same issue. Contact the plugin author before randomly deleting indexes.
From the MySQL command line you can execute the DROP INDEX command as often as necessary based on how many duplicate indexes appear:
mysql> DROP INDEX sl_store_2 ON wp_store_locator; mysql> DROP INDEX sl_latitude_2 ON wp_store_locator; mysql> DROP INDEX sl_longitude_2 ON wp_store_locator;
You should leave the indexes without the _# intact.
The Automated Fix
I am looking into ways to detect and auto-delete the secondary indexes in Store Locator Plus in the 3.9.X+ updates, however there is a danger of bloating the update/install process which I want to avoid. I am also looking for ways to prevent the problem from happening in the first place and have been active with the reported bug to see if there is a way to get WordPress Core developers to patch the problem.
If a workaround is found it will be noted in the updates road map for SLP.
Alexa Rank: 264,930 / 89,424 / 611
Technorati Rank: 27347