# mysql tables crashing **URL:** \ **Category:** Other MySQL® Questions\ **Created:** [August 27, 2007, 3:55am UTC](https://forums.percona.com/t/mysql-tables-crashing/423 "2007-08-27T03:55:28Z")\ **Posts on this page:** 14\ **Page:** 3
**Author:** ![allworknoplay](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@allworknoplay](https://forums.percona.com/u/allworknoplay)\ **Post date:** [September 15, 2007, 10:46am UTC](https://forums.percona.com/t/mysql-tables-crashing/423/41 "2007-09-15T10:46:30Z")
| [B]jcn50 wrote on Sat, 15 September 2007 12:04[/B] | | Ok, don't forget to change the thread\_concurrency to 1 too. | I made a boo-boo. I repaired the table and changed my script to DELETE QUICK. Walked away, made some coffee, 20 mins later I came back and I got an email again my table got corrupted. This time it was FAST. Usually 2-3 days, but never within 20 mins of REPAIRING a table. So I said, that’s it, I am dropping this INDEX because it’s causing too many problems… Low and behold, I forgot to clear out my mysql error log file, so when my script ran, it emailed me because it thought the table was corrupted!!! The key is to drink coffee first!!! So now I have a DELETE QUICK AND I dropped the Index on the ID column. Now if the table never gets corrupted again, I will not know which one was the actual solution!!! ---
**Author:** ![jcn50](https://avatars.discourse-cdn.com/v4/letter/j/8baadc/32.png) [@jcn50](https://forums.percona.com/u/jcn50)\ **Post date:** [September 17, 2007, 8:36am UTC](https://forums.percona.com/t/mysql-tables-crashing/423/42 "2007-09-17T08:36:50Z")
How is the debugging doing? ---
**Author:** ![allworknoplay](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@allworknoplay](https://forums.percona.com/u/allworknoplay)\ **Post date:** [September 17, 2007, 4:30pm UTC](https://forums.percona.com/t/mysql-tables-crashing/423/43 "2007-09-17T16:30:21Z")
| [B]jcn50 wrote on Mon, 17 September 2007 10:06[/B] | | How is the debugging doing? | So far no crash…so that is good. Still need to finish off the error output logs if I can’t make a successful mysql query… But I’m starting to feel a little better now… Don’t want to jinx anything though!!! ---
**Author:** ![jcn50](https://avatars.discourse-cdn.com/v4/letter/j/8baadc/32.png) [@jcn50](https://forums.percona.com/u/jcn50)\ **Post date:** [September 17, 2007, 4:37pm UTC](https://forums.percona.com/t/mysql-tables-crashing/423/44 "2007-09-17T16:37:58Z")
Let’s make a party on October the 1st if no more crash! 😃 ---
**Author:** ![allworknoplay](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@allworknoplay](https://forums.percona.com/u/allworknoplay)\ **Post date:** [September 17, 2007, 4:54pm UTC](https://forums.percona.com/t/mysql-tables-crashing/423/45 "2007-09-17T16:54:07Z")
| [B]jcn50 wrote on Mon, 17 September 2007 18:07[/B] | | Let's make a party on October the 1st if no more crash! :D | I think you’re trying to jinx me!!! ---
**Author:** ![Peter](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/peter/32/2_2.png) [@Peter](https://forums.percona.com/u/Peter)\ **Post date:** [September 18, 2007, 8:48am UTC](https://forums.percona.com/t/mysql-tables-crashing/423/46 "2007-09-18T08:48:42Z")
thread\_concurrency makes no difference on Linux. It is also just a hint to the scheduler on how to schedule threads - it has nothing to do with a way MySQL runs threads internally. Now you’ve tot the bug - I’d try to get our repeatable test case and get it to [bugs.mysql.com](http://bugs.mysql.com) I know there ARE MyISAM corruption bugs out where. ---
**Author:** ![ymik](https://avatars.discourse-cdn.com/v4/letter/y/3bc359/32.png) [@ymik](https://forums.percona.com/u/ymik)\ **Post date:** [September 30, 2007, 10:45am UTC](https://forums.percona.com/t/mysql-tables-crashing/423/47 "2007-09-30T10:45:02Z")
Hello All. We have some throuble with our DB. When we cast request such as “update user lastactyvity=12131241234 WHERE userid in (1,2,3,4,5,6,7…)” we got error “Table ‘%-.64s’ is marked as crashed and should be repaired” and our replication is fault. What thing can produse this error with unknown table ‘%-.64s’? How can we relieve from this bug? Tables is on MyISAM, MySQL version is 5.0.32-Debian\_7etch1 ---
**Author:** ![allworknoplay](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@allworknoplay](https://forums.percona.com/u/allworknoplay)\ **Post date:** [October 4, 2007, 7:57am UTC](https://forums.percona.com/t/mysql-tables-crashing/423/48 "2007-10-04T07:57:23Z")
Well after a successful 3 weeks, I came to work only to find that my table has crashed. This is what MYSQL error log shows: [ERROR] /usr/local/mysql/libexec/mysqld: Incorrect key file for table ‘./collector/data\_day.MYI’; try to repair it I think part of the cure is for me to separate this table into multiple tables so that it is not being hammered so much, part of the problem I think is that I have many types of data in it and perhaps the scripts are all fighting for the table’s resources??? ---
**Author:** ![jcn50](https://avatars.discourse-cdn.com/v4/letter/j/8baadc/32.png) [@jcn50](https://forums.percona.com/u/jcn50)\ **Post date:** [October 4, 2007, 5:10pm UTC](https://forums.percona.com/t/mysql-tables-crashing/423/49 "2007-10-04T17:10:33Z")
I’ll suggest a last attempt: a conversion to INNODB. If an INNODB conversion doesn’t change anything, it’s an hardware problem (hard drive is having bad sectors/blocks). We’ve tried everything on this. INNODB is the last (software) solution I could think of, since we’ve done our homework. ---
**Author:** ![jcn50](https://avatars.discourse-cdn.com/v4/letter/j/8baadc/32.png) [@jcn50](https://forums.percona.com/u/jcn50)\ **Post date:** [October 4, 2007, 5:27pm UTC](https://forums.percona.com/t/mysql-tables-crashing/423/50 "2007-10-04T17:27:46Z")
Sorry man, we didn’t reply because you need to follow this thread from the beginning to know where your errors come from… If you think it’s a bug, update for the last version of the mySQL engine. I’m not aware of any known “Table ‘%-.64s’” error… Good luck! | [B]ymik wrote on Sun, 30 September 2007 16:15[/B] | | Hello All. We have some throuble with our DB. When we cast request such as “update user lastactyvity=12131241234 WHERE userid in (1,2,3,4,5,6,7…)” we got error “Table ‘%-.64s’ is marked as crashed and should be repaired” and our replication is fault. What thing can produse this error with unknown table ‘%-.64s’? How can we relieve from this bug? Tables is on MyISAM, MySQL version is 5.0.32-Debian\_7etch1 | ---
**Author:** ![allworknoplay](https://avatars.discourse-cdn.com/v4/letter/a/dbc845/32.png) [@allworknoplay](https://forums.percona.com/u/allworknoplay)\ **Post date:** [October 5, 2007, 7:14am UTC](https://forums.percona.com/t/mysql-tables-crashing/423/51 "2007-10-05T07:14:08Z")
| [B]jcn50 wrote on Thu, 04 October 2007 18:40[/B] | | I'll suggest a last attempt: [URL="http://forum.mysqlperformanceblog.com/s/mv/msg/394/1824/"]a conversion to INNODB[/URL]. If an INNODB conversion doesn't change anything, it's an hardware problem (hard drive is having bad sectors/blocks). We’ve tried everything on this. INNODB is the last (software) solution I could think of, since we’ve done our homework. | Your code is really coming in handy. I am seeing a lot of duplicate errors. But in my script the code is something like… INSERT INTO … IF DUPLICATE THAN UPDATE… That’s basically what I’m doing in my code and your code is pinpointing exactly that line from my code… I am going to try one more thing before I have to convert to INNODB because I just don’t know INNODB that well… I have begun separating the table into many tables, this in a way will share the load of INSERTS and balance it out… Also, I should run OPTIMIZE TABLE once a week like on a Saturday… ---
**Author:** ![alva](https://avatars.discourse-cdn.com/v4/letter/a/c4cdca/32.png) [@alva](https://forums.percona.com/u/alva)\ **Post date:** [November 27, 2015, 1:51am UTC](https://forums.percona.com/t/mysql-tables-crashing/423/52 "2015-11-27T01:51:44Z")
Repairing table using MySQL console If got the shell access then connect to MySQL server and perfrom the following steps: > use my\_database; > repair table my\_crashed\_table; To repair crashed MySQL table using PHPMyAdmin follow the this steps Log on PHPMyAdmin \> choose affected database \> choose affected table from right pane \> from With selected menu, choose “Repair table”. More info visit: [http://mysql.filerepairtool.net/blog/mysql-table-marked-crashed-repaired](http://mysql.filerepairtool.net/blog/mysql-table-marked-crashed-repaired) ---
**Author:** ![plastico](https://avatars.discourse-cdn.com/v4/letter/p/ce7236/32.png) [@plastico](https://forums.percona.com/u/plastico)\ **Post date:** [December 14, 2015, 3:46pm UTC](https://forums.percona.com/t/mysql-tables-crashing/423/53 "2015-12-14T15:46:32Z")
The DB can keep up, simply because all INSERTs are put on a waiting list, but some scripts may hang the server (waiting for the INSERT query to complete), and then timeout. In that case you can use “INSERT DELAYED”: your scripts will not wait for the INSERT to be completed anymore, and your mySQL server will execute the INSERT query when the load will be lower. * * * [URL][http://plasticobiodegradable.com/polipropileno-todo-lo-que-tienes-que-saber/[/URL]](http://plasticobiodegradable.com/polipropileno-todo-lo-que-tienes-que-saber/%5B/URL%5D) ---
**Author:** ![jokipokemon2](https://avatars.discourse-cdn.com/v4/letter/j/a9a28c/32.png) [@jokipokemon2](https://forums.percona.com/u/jokipokemon2)\ **Post date:** [October 26, 2016, 4:33am UTC](https://forums.percona.com/t/mysql-tables-crashing/423/54 "2016-10-26T04:33:23Z")
What I meant by “overflow INSERT” is something like this: - having a table with a TEXT (or BLOB) field/column - INSERT a variable, let’s call it $in - make the mySQL query with a PHP script using $in [where it should be using substr($in,65530)] - your mySQL query crash (not the server, only the query) so your INSERT is not recorded into the DB - next / others queries are proceeded. * * * [Lampu Jalan Tenaga Surya](http://lampusurya.com) [Previous page](https://forums.percona.com/t/mysql-tables-crashing/423.md?page=2)