Why does phpMyAdmin show an empty cardinality?
If I edit the index (without change anything) and save, the cardinality will appear, but after a TRUNCATE and some INSERTs, the cardinality become empty again.
Running
ALTER TABLE tableName ENABLE KEYS
doesn't help.
How to make the cardinality always present?
Edit:
The phpMyAdmin version is 4.6.4
The MySql version is libmysql - mysqlnd 5.0.12-dev - 20150407
The Engine is MyISAM
You need to analyze the table.
ANALYZE LOCAL TABLE tablename
The stats for the primary key are updated when the data is updated, but the other indexes need this operation to set a value. Note that if the distribution of the data is not changing then you don't need to refresh the indexes.
Note that there is a performance impact (and locking impact with MyISAM) on large tables when you run this.
Aha -- I found NULLs with SHOW INDEXES on a MyISAM table. Is yours ENGINE=MyISAM? Recommend changing to InnoDB.
Related
I am running MySQL 5.6.13 and I would like to run a CREATE INDEX ... BTREE statement on my production database.
The table is InnoDB and has ~ 4 million rows, and I would like very much not to lock it.
According to the docs, it appears as if this statement will not completely lock my table and return quickly. But, I wanted a second opinion before I made this change.
Would it be safe to create this index?
By default, InnoDB in MySQL 5.6 will perform a read lock while creating the index, so you can still have other concurrent clients SELECT from the table, but not do insert/update/delete on that table while the index is being created.
You can optionally allow the index creation to be completely online and not even do the read lock:
ALTER TABLE my_table ADD INDEX a (a), LOCK=NONE;
See http://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html for more details about online DDL statements in MySQL.
Also see this blog posted today from a MySQL Community Manager: Top 10 advances to availability since MySQL 5.5
PS: It's not necessary to specify BTREE for the index type. InnoDB supports only BTREE indexes, so it ignores that option.
Today I tried to reorder a column of a table using phpMyAdmin (as I have done many times before).
Although the result was displayed as successful no reordering effectively happened.
It appears the problem is caused by using InnoDB as storage engine which is the default value from MySQL 5.5 onward.
When I changed back to myIsam the problem was solved. It clarified why it was working on some tables.
Is this a solvable mySQL problem? Or is this regular expected behavior for InnoDB ?
In the latter case phpMyAdmin should perhaps be adapted to not offer the functionality while using InnoDB.
MySQL: 5.5.29
phpMyAdmin: 4.0.4
If by ...reordering column... you meant
ALTER TABLE ... ORDER BY ...
then for InnoDB table that has a PRIMARY or UNIQUE KEY it doesn't work. It's by design:
ALTER TABLE
ORDER BY does not make sense for InnoDB tables that contain a
user-defined clustered index (PRIMARY KEY or NOT NULL UNIQUE index).
InnoDB always orders table rows according to such an index if one is
present.
On the other hand if you don't have PRIMARY or UNIQUE KEY in your table, which is highly unlikely, then MySQL will allow you to change the order.
Here is SQLFiddle demo that demonstrates that behavior.
I'm trying to reverse a date type index on a InnoDB database schema via. MySQL Workbench
But every time i try to apply the changes they are ignored?
Do i need to use the command line to configure the database?
According to http://www.oracle.com/partners/en/knowledge-zone/mysql-5-5-innodb-myisam-522945.pdf
Page 10. InnoDB supports BTREE indexes.
I have MySQL running on my machine configured with MyISAM as its default tables.
Now I want to ask few of questions:
1) If I change the default table to InnoDB in the configuration file (my.conf), clear the log file and restart mysql, would that harm any of my previous database or tables?
2) If I alter few tables' engine to InnoDB using the following command, would that affect its data at all?
ALTER TABLE table_name ENGINE = InnoDB;
3) Is it a good idea to keep few tables as MyISAM (for read and write) and the rest as InnoDB (more for selecting data) or is it preferred to select one engine for all the tables in the database?
2) It will only affect the internal representation. Nothing that you will notice on the outside.
3) It is a perfectly good idea, if it enhances performance.
2) You can mix database types. i.e. innoDB and MyISAM.
3) innoDB supposedly keeps data safer. I think it is the default on latest versions of mySQL.
I m getting the error - The storage engine for the table doesn't support repair
while repairing the tables through command - mysqlcheck -u root -p --repair "database"
It displays error for 4 tables only out of 106 tables , for rest of the tables it displays OK.
Pls help if there is any work around.
Thanks.
Myisam engine supports this functionality and I believe these 4 tables are not myisam type.
as manual says :
The MyISAM storage engine supports all
four maintenance operations, so
mysqlcheck can be used to perform any
of them on MyISAM tables. Other
storage engines do not necessarily
support all operations. In such cases,
an error message is displayed. For
example, if test.t is a MEMORY table,
an attempt to check it produces this
result:
For further Detail see myisamcheck
You can change the engine of tables if they fit for myisam
You cannot repair an InnoDB type table, If you want to repair them you’ll have to change the table engine from InnoDB to MyIsam.
To Do this, follow these simple steps
Open your phpmyadmin
Select the database you want to repair.
Look for the table(s) with InnoDB type storage engine and note down their names.
Now you need to perform an SQL command by clicking on the SQL tab that appears on the top section of that page.
Now use the command given below
ALTER TABLE table_name ENGINE=MyISAM;
Replace the table_name with the name of the table you want to change from InnoDB to MyISAM.
Note: You will have to do the table change one by one. For each time, chose one table and change its engine and so on.
Source: Error in mysql repair-The storage engine for the table doesn’t support repair while repairing | cPanelWhm.org