I'm using MySQL v4.0.12 on Redhat Linux 9.0 I have a python script (using the MySQLdb module) that inserts a large batch of records to several MyISAM tables. The largest table (named 'log') has 20 columns. A single column defines the primary key. There isn't an auto increment column. Many of the other columns in the log table are indexed as well.
This seemed like an ideal case to DISABLE KEYS, insert the data and then ENABLE KEYS based on the MySQL documentation. And running some time tests proves that this approach runs much faster. However, in doing so, the log table becomes corrupted (or at least the indecies do). mysql> select * from log order by log_id; ERROR 1030: Got error 124 from table handler If I execute the same query without the order by clause things behave as normal. It seems as though the indecies (I've tried several of them) have become corrupted. I have tried write locking all of the tables prior to disabling the keys but that does not fix the problem. If I run mysqlcheck or 'REPAIR TABLE log;' the table/indecies behave normally. The question is this-- why do I need to repair the table in order for it to be usable? If I remove the disable/enable keys there are no indexing problems. The problem occurs only when the keys are disabled and enabled. Has anyone encountered this behavior before? Is it normal for me to *have* to run a repair table statement in order for this to work? Thank you for any information, Phil -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
