I am trying to convert a very big table to InnDB. But it throws an error.
Here is the screenshot of the issue which came after running for 5 minutes.
UPDATE: This is a live production table where live data are coming. Seems like the auto_increment column is causing the issue. By the time the it applies the InnoDB engine new records are coming and the auto_increment is increased again.
Did you check official mysql documentation ? There is one useful text, maybe can help.
https://dev.mysql.com/doc/refman/8.0/en/converting-tables-to-innodb.html
Maybe just to try with ALTER TABLE your_table ENGINE=InnoDB;
I mean, without auto increment.
Related
The table whose engine needs to be converted is only for read purpose and its content will never change. So I want to convert the engine of the table as ARCHIVE, but when I tried to convert it, I got the error below.
Error Code: 1069. Too many keys specified; max 1 keys allowed
The version of MySQL is 5.5.
Is this index related problem?
Looks like it definitely is a PK problem since archive does not support primary keys. You can simply drop the primary key and it should work.
Refer to this post for examples on how to convert your db
I am trying to run some basic CREATE TABLE statements for my Databases course project and am getting some strange errors.
When I create the table Manuf it runs fine, but when I try to create the next table, Order, using the same syntax, it does not work.
Also, when I try to create this table, Items, I get an errno: 150. I believe this has to do with my foreign key creation, but I am not exactly sure. Here is a screenshot of that.
I am fairly new to using MySQL so any advice would be greatly appreciated, thank you.
The error on the Order table is caused by ORDER being a reserved word. You can specify it as `Order` with the backticks, but it's better if you choose a different name altogether.
The error 150 is related to the foreign key. The keys must be absolutely identical - the exact same definition, or the FK will fail with error 150.
Also, there must be an available index with that key definition or one compatible (see Kai Baku's example in the comment on the MySQL manual page). The same fields indexed in a different order will fail.
To begin with, check how those keys are defined in the origin tables. For example:
test1 varchar(50) not null
test2 varchar(50)
will not be compatible. I think that even a different collation is enough to throw FK off kilter (but this I haven't checked. The rest I'm sure of, from my personal bitter unexperience).
UPDATE: I forgot to mention, if you use InnoDB tables and issue the SHOW ENGINE INNODB STATUS, the blurb that comes out will contain a much better explanation of why the FK failed, somewhere about one third from top.
I am quite new to MySQL and I have encountered a problem that I find quite puzzling. If I create a table with MySQL Workbench, when I set the PK I can choose it to auto-increment or not, as should be. However, if I change my mind later on, once the table has been created, I cannot alter the auto-increment flag any longer, as MySQL tells me that the "table already exists". That happens even if the table is empty.
The auto-generated SQL is as follows:
ALTER TABLE tablename
CHANGE COLUMN `ID` `ID` INT(11) NOT NULL AUTO_INCREMENT ;
and it fails with the error stated above. I have tried changing the algorithm and lock type, to no avail.
This does not happens in T-SQL or Oracle, for instance, so I fail to see a reason why it should fail in MySQL. Is there any way to fix this without having to drop and re-create the table?
Thanks.
From experience all the GUIs get a bit confused when you start changing primary keys, the number of error messages I've seen from SQL Server...
You don't need to drop the whole table, but it might be easiest to drop and then re-create the offending column.
Also, check out the MySQL dev docs, but I think either ALTER or MODIFY column are the two I'd go for and I'm not sure why the column name is there twice if you're not renaming it.
Ok, I discovered the culprit thanks to dbForge Studio. The same thing happens there, but this time the error is more explicit: I cannot change the auto-increment flag apparently because it is used as a foreign key on another table. I deleted the FK and then I was able to set the auto-increment.
Thank you all who helped me, I have learned some new things thanks to your comments.
When inserting data in mysql i get this error:
Error Number: 1467
Failed to read auto-increment value from storage engine
I don't now how to solve this issue please any help will be appreciated.
After some searching i found the answer and it solved my problem.
run this sql query it will fix the problem
ALTER TABLE `YOUR_TABLE` AUTO_INCREMENT =1
To add a little comment to kiddingmu's answer: it is not just a question of the number of digits, but also of the range of the datatype.
If the column is INT(11), the 11 says that 11 digits are used for display; but this does not release the constraint that INT can only encode the range -2147483648:2147483647 when signed, and 0:4294967295 when unsigned.
So: for an INT(11) column, an AUTO_INCREMENT of 10000000000 will work; an AUTO_INCREMENT of 90000000000 will not, despite it being 11 digits.
If a larger range is needed, then another type should be used, like BIGINT.
I received this message too. My problem was that my table was not sorted by index. Try using the following:
ALTER TABLE `YOUR-TABLE` ORDER BY `index` ;
One possible explanation for this behavior is that the autoincrement value has reached the maximum value for the datatype, and its not possible for the database engine to increment it by one.
I suggest you check the current value. One relatively easy way to do that is to run a SHOW CREATE TABLE mytable;, the table definition will show the current value. (You can also query the information_schema.tables view, to get the same information.)
As spencer7593 says, the autoincrement value has reached the maximum value for the datatype
I just came to the problem.
use the command SHOW CREATE TABLE tablename;, I get
table name {
`id` int(11) NOT NULL AUTO_INCREMENT,
......
}ENGINE=InnoDB AUTO_INCREMENT=100000000000 DEFAULT CHARSET=utf8
You will see the length of 100000000000 is 12, beyond the limit 11.
Check your database structure properly. I have also faced this problem, but I found some error in database structure. After fix the structure, problems were resolved.
Another possibility with this error is that you've hit the max value in the ID field (generally an INT). We had this error when our ID values got close to 4294967295. We ended up having to drop the ID from the table in order to get past the issue. The various INT fields are mentioned in this answer: https://stackoverflow.com/a/5634147/4573630
I had the same problem, after changing ID column to id, and after exporting my db, so I just switched the column back to ID and then back to id again, and every thing worked fine after. Working with elequent orm in laravel, it expects column id and I had column ID, that is why I changed it in the first place
**For me it was the auto increment ID(column) that brings about the Error **
What i just do to solve it is i drop(delete) the ID column and add it again.
ps aux | grep mysql
sudo kill (your pid)
/etc/init.d/mysql restart
Please help I am in major trouble with our production database. I had accidentally inserted a key with a very large value into an autoincrement column, and now I can't seem to change this value without a huge rebuild time.
ALTER TABLE tracks_copy AUTO_INCREMENT = 661482981
Is super-slow.
How can I fix this in production? I can't get this to work either (has no effect):
myisamchk tracks.MYI --set-auto-increment=661482982
Any ideas?
Basically, no matter what I do I get an overflow:
SHOW CREATE TABLE tracks
CREATE TABLE tracks (
...
) ENGINE=MYISAM AUTO_INCREMENT=2147483648 DEFAULT CHARSET=latin1
After struggling with this for hours, I was finally able to resolve it. The auto_increment info for myISAM is stored in TableName.MYI, see state->auto_increment in http://forge.mysql.com/wiki/MySQL_Internals_MyISAM. So fixing that file was the right way to go.
However, myisamchk definitely has an overflow bug somewhere in the update_auto_increment function or what it calls, so it does not work for large values -- or rather if the current value is already > 2^31, it will not update it (source file here -- http://www.google.com/codesearch/p?hl=en#kYwBl4fvuWY/pub/FreeBSD/distfiles/mysql-3.23.58.tar.gz%7C7yotzCtP7Ko/mysql-3.23.58/myisam/mi_check.c&q=mySQL%20%22AUTO_INCREMENT=%22%20lang:c)
After discovering this, I ended up just using "xxd" to dump the MYI file into a hexfile, edit around byte 60, and replace the auto_increment value manually in the hexfile. "xxd -r" then restores the binary file from the hex file. To discover exactly what to edit, I just used ALTER TABLE on much smaller tables and looked at the effects using diffs. No fun, but it worked in the end. There seems to be a checksum in the format, but it seems to be ignored.
Have you dropped the record with the very large key? I don't think you can change the auto_increment to a lower value if that record still exists.
From the docs on myisamchk:
Force AUTO_INCREMENT numbering for new records to start at the given value (or higher, if there are existing records with AUTO_INCREMENT values this large)