Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.1.6-1, 10.1.6-2, 10.1.7-1, 10.2.0-5, 10.2.0-6, 5.5.51 & 10.2.2
Description
MDEV-7829 and MDEV-7363 where attempts to work around the implementation of analyze table because holding a read lock only on the entire table while gathers statistics. This can be up to an hour or so on larger tables as witnessed in production databases. This level of total read only on a table isn't acceptable.
MDEV-7196 suggested by jplindst indicated that perhaps a full scan is more appropriate to give better statistics. Obviously this isn't going to help the locking scenario at all.
So perhaps, instead of locking the entire table, the analyze table takes a full table scan in incremental blocks. These block sizes should try to scale to something that keeps the lock time less that a goal time, a new variable max_analyze_table_lock_time (locks can be dropped in analyze table gets there too soon). Analyze table being a long running operation should drop to read committed (or uncommitted?) mode to keep the undo logs from growing because of the intensive read operations.
Attachments
Issue Links
- is blocked by
-
MDEV-24733 Doc bug: ANALYZE TABLE
- Closed
- relates to
-
MDEV-10494 re-implement analyze table for even lower impact
- Open
-
MDEV-10555 Server crashes in mysql_admin_table upon killing ANALYZE
- Closed
-
MDEV-7196 ANALYZE TABLE should do complete table scan
- Open
-
MDEV-7363 bulk engine-independent index stats manipulation restricted due to ER_WRONG_LOCK_OF_SYSTEM_TABLE
- Closed
-
MDEV-7829 Could not execute Update_rows_v1 event on table mysql.table_stats; Can't find record in 'table_stats'
- Closed