Mimir v1.0.28

Mimir changelog - 1.0.26 to 1.0.28

• Fixed: the "list tables by size" query (information_schema.tables with data_length/index_length) used to walk every row of every table, so on a big database it took tens of seconds and could blow past a control panel's timeout and return nothing. Two fixes: sizes no longer reassemble overflowed values just to measure them (a 250 MB table went ~1.5 s to 0.006 s), and per-table row/byte counts are now kept as maintained statistics instead of being counted on demand.
• Result on a real 3.6 GB dump (biggest table 19.5M rows): the table list went from timing out to ~0.001 s, with no change to import speed. Counts are approximate and page-aligned, exactly like InnoDB reports.
• Backward-compatible with databases from older versions; freshly imported data is fast immediately.

1.0.27 - Laravel / Doctrine apps can connect (FreeScout, etc.)

• Fixed: session-setup statements sent as prepared statements (SET NAMES … COLLATE …, SET sql_mode, SET time_zone, USE) were rejected with 1064 unsupported statement. Laravel/Doctrine run these through a prepared statement when opening a connection, so the connection failed before any query - breaking FreeScout and other Laravel/Symfony apps entirely. They're now handled on the prepared path like normal queries.

1.0.26 - WordPress taxonomy queries no longer peg the CPU

• Fixed: a nested-loop join only used its index when the join condition was written one way. WordPress core writes its joins with the outer table's column on the left (e.g. ... ON t.term_id = tt.term_id), the orientation that fell back to a full table scan - turning the core taxonomy query every page runs into O(n²)/O(n³). On a real site the 3-table get_object_terms join took 7.7 s; with many running at once, every CPU core pegged. The planner now uses the index regardless of which side the column is on: 7.7 s → 0.1 s (~70×). Results are identical - it's a pure access-path change. Recommended for any site that uses taxonomy/term queries (nearly all of them).