What is the MySQL statement to alter the row_format to dynamic?
I am not sure how I am supposed to do it (i.e. using the information_schema or by using a table ALTER).
try
ALTER TABLE `test` ROW_FORMAT=DYNAMIC;
The method I've used, based on the current Oracle docs, is because the COMPACT tables I have were only set based on the default, which has now changed. This is on a MariaDB 10.2 system for me, but will work on modern MySQL systems.
Specifically, ensure default is DYNAMIC (or the format you need):
SET GLOBAL innodb_default_row_format=DYNAMIC;
Then OPTIMIZE the tables you need to change;
OPTIMIZE TABLE database.tablename;
This works, because the row_format is updated to the server default on an "operation that rebuilds a table silently", to quote the documentation.
Related
i want to change table character set from 'utf8' to 'utf8mb4'
but each column has own character set setting(utf8)
so i need to change column character set to 'Table Default', but locking is the problem
help me to change column character set without table locking
there is over 100,000,000 rows in table
"Character set" is the encoding of the characters in bytes.
"Collation" is how to sort characters.
An INDEX on a VARCHAR is sorted by its collation, so changing the collation of a column requires rebuilding an index -- a non-trivial operation.
The difference between utf8 and utf8mb4 is relatively minor, but I don't think MySQL (hence RDS) has made a special case of that.
ALTER TABLE t CONVERT TO utf8mb4; sounds like the operation that you desire. That requires ALGORITHM=COPY, so it is 'locking'.
Look into pt-online-schema-change and gh-ost as a way of altering a table, even when it needs to "copy". These are essentially non-blocking. However, I do not know if they can be used with RDS. Also, because of JOINs and other cases where one table may need to be consistent with another, those tools may not be practical.
Another approach... Add another column(s); change your code to use both the old and new column(s). Meanwhile, gradually copy the old values to the new column(s); when this is finished, change your code again -- this time to use the new column(s) instead of the old. At some later date, worry about dropping the dead column(s).
Recent versions of MySQL have made significant changes in the speed of ALTER, so be sure to study what version RDS is derived from. In 5.6, ADD COLUMN can use ALGORITHM=INPLACE; in 8.0, ALGORITHM=INSTANT. I think either of those is non-"locking" for your purposes. (DROP COLUMN is not cheap; the issues with JOIN and rebuilding indexes are still up in the air.)
If you try one of these techniques, I strongly recommend you build a table with at least a million rows and try out all the steps (alter add, join, recreate index, alter drop column, etc) to verify what parts are "fast enough" and/or "non-locking".
Table storage engine for <TABLE> doesn't have this option.
This is the error returned by MySQL on an order by query. The column type is varchar(2000).
Query:
select * from `dbo.table_1` order by textT;
Error returned:
ERROR 1031 (HY000): Table storage engine for 'dbo.table_1' doesn't have this option.
Why does this happen? And how can I fix it?
This problem appears to occur when you're importing a table definition that had been created with MyISAM but later was switched to InnoDB; the resulting ROW_FORMAT options appear to be invalid.
If you're trying to import an exported database and encounter this problem, you can simply search and replace ROW_FORMAT=FIXED with nothing.
I used the following to do so really quickly:
sed -ie 's/ROW_FORMAT=FIXED//g' backup.sql
Problem solved! Thanks to jbrahy for pointing out that it was the ROW_FORMAT that was the problem.
EDIT: Updated to work for more platforms as per #seven's suggestion
EDIT2: Also note, as per #Steen-Schütt, this may be a safer fix
sed -ie 's/ROW_FORMAT=FIXED/ROW_FORMAT=COMPACT/g' backup.sql
You can also try this:
ALTER TABLE `dbo.table_1` ROW_FORMAT = DEFAULT ;
I get the same error when I import a table definition that's InnoDB with ROW_FORMAT=DYNAMIC in it. The table was created with a MyISAM engine but I later switched it to InnoDB. When I removed the ROW_FORMAT=DYNAMIC from the create table statement and recreated the table it worked fine. My solution to your problem would be this.
show create table `dbo.table_1`;
then take the output from that command and remove the ROW_FORMAT=DYNAMIC then rename the table to dbo.table_1_old
rename table `dbo.table_1` to `dbo.table_1_old`;
Then execute the create table statement from the first step i.e.
-- don't use this create as there are missing columns use yours
create table `dbo.table_1` (textT VARCHAR(255));
Then repopulate your table with the old data.
insert into `dbo.table_1` select * from `dbo.table_1_old`;
Then you should be able to execute your original SQL
select * from `dbo.table_1` order by textT;
This problem appears to occur when you're importing a table definition to MySQL 5.7 that had been created with MySQL 5.6 and earlier. The same error can produceb by option KEY_BUFFER_SIZE=8192 and similar sizes defined in bytes for INNODB ENGINE.
I had this error when I'm importing base from sql-dump.
Decision: sed -ie 's/KEY_BLOCK_SIZE=16384//g' my-file-sql_dump.sql
I was facing this problem and my backup file was encrypted .zsql file. So I modified my.cnf by adding innodb_strict_mode = off. It worked fine
I just saw that MySQL 5.5 offers utf8_general_mysql500_ci as collation.
What is the difference to other collations like utf8_general_ci?
Should I better use utf8_general_mysql500_ci?
As documented under Changes in MySQL 5.5.21:
New utf8_general_mysql500_ci and ucs2_general_mysql500_ci collations have been added that preserve the behavior of utf8_general_ci and ucs2_general_ci from versions of MySQL previous to 5.1.24. Bug #27877 corrected an error in the original collations but introduced an incompatibility for columns that contain German 'ß' LATIN SMALL LETTER SHARP S. (As a result of the fix, that character compares equal to characters with which it previously compared different.) A symptom of the problem after upgrading to MySQL 5.1.24 or newer from a version older than 5.1.24 is that CHECK TABLE produces this error:
Table upgrade required.
Please do "REPAIR TABLE `t`" or dump/reload to fix it!
Unfortunately, REPAIR TABLE could not fix the problem. The new collations permit older tables created before MySQL 5.1.24 to be upgraded to current versions of MySQL.
To convert an affected table after a binary upgrade that leaves the table files in place, alter the table to use the new collation. Suppose that the table t1 contains one or more problematic utf8 columns. To convert the table at the table level, use a statement like this:
ALTER TABLE t1
CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;
To apply the change on a column-specific basis, use a statement like this (be sure to repeat the column definition as originally specified except for the COLLATE clause):
ALTER TABLE t1
MODIFY c1 CHAR(N) CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;
To upgrade the table using a dump and reload procedure, dump the table using mysqldump, modify the CREATE TABLE statement in the dump file to use the new collation, and reload the table.
After making the appropriate changes, CHECK TABLE should report no error.
For more information, see Checking Whether Tables or Indexes Must Be Rebuilt, and Rebuilding or Repairing Tables or Indexes. (Bug #43593, Bug #11752408)
I've discovered that MySQL has multiple row formats, and it's possible to specify this or change it. Also, the default ROW_FORMAT has apparently changed over time with MySQL versions, which is understandable.
However, I can't find anywhere that says how to find out what the ROW_FORMAT of an existing table is! My database has been around for years, from older versions of MySQL, and I want to make sure I'm not using a poorly performing ancient disk format.
How do I find out the ROW_FORMAT of a table in MySQL?
Information schema offers a wealth of information.
SELECT row_format FROM information_schema.tables
WHERE table_schema="YOUR DB" AND table_name="YOUR TABLE" LIMIT 1;
2014.06.19 - Mild Update
The following query will give you the row format of all tables in the current database:
SELECT `table_name`, `row_format`
FROM `information_schema`.`tables`
WHERE `table_schema`=DATABASE();
With following query:
show table status like 'table_name';
I am using mysql and mysql workbench. I created 5 tables with innodb engine. I checked their engine and it was innodb before I insert data into them. I inserted data from 5 MyISAM tables and now my innodb tables are MyISAM. I can't change them. I used the alter table engine=innodb but it doesn't work.
From the manual: http://dev.mysql.com/doc/refman/5.1/en/alter-table.html
For example, to convert a table to be an InnoDB table, use this statement:
ALTER TABLE t1 ENGINE = InnoDB;
The outcome of attempting to change a table's storage engine is affected by whether the desired storage engine is available and the setting of the NO_ENGINE_SUBSTITUTION SQL mode, as described in Section 5.1.11, “Server SQL Modes”.
https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#sqlmode_no_engine_substitution
When you create the table do you get any warning about the Engine type being unavailable?
It's not obvious. If you edit the table and then select the column tab the engine widget is not immediately visible. On the upper right of the edit window you will see two down pointing chevrons. Select the arrow once and additional widgets will appear. In the upper right hand corner there will now be widgets for the schema and engine.