I am writing this a follow up to Changing data type of column in SQL Server
My question earlier was if I need to remove all indexes and constraints and it was answered I do need to remove them.
So as I was surf internet on the topic I came across a few post saying its better to disable and enable an index, rather than removing and recreating them .
So which is better way of doing it? Does disabling of index allow you to change the data type of the column as well? What is the difference between both?
Statement with dropping and creating index
DROP INDEX UX_1_COMPUTATION ON dbo.Computation
ALTER TABLE dbo.Computation
ALTER COLUMN ComputationID NVARCHAR(25) not null
CREATE UNIQUE INDEX UX_1_COMPUTATION ON dbo.Computation (ComputationID);
Statement with disabling and enabling index
ALTER INDEX [UX_1_COMPUTATION ] ON dbo.Computation DISABLE
ALTER TABLE dbo.Computation
ALTER COLUMN ComputationID NVARCHAR(25) not null
ALTER INDEX [UX_1_COMPUTATION ] ON dbo.Computation REBUILD;
Does disabling of index allow you to change the data type of the column as well?
It is based on the index type you choosed. You cannot modify a column data type when an clustered index on the table is disabled. If your index is a non clustered index then you can.
What is the difference between both?
The biggest difference between disabling and dropping an index is whether the metadata and statistics are persisted. If disabled, they are. If dropped, they are not. Make sure you carefully weigh your options before performing either action, and always have a way to recreate the index available.
which is better way of doing it?
In your case I would suggest drop and recreate indexes.
Related
Is it possible to alter a MySQL unique index to non-unique without recreating it (DROP and CREATE)?
I'm using MySQL version 8.0.19.
No, in MySQL it is not possible to change the definition of an index without dropping it and recreating it. There is no ALTER INDEX statement.
Correction: You can rename an index without rebuilding it. You can make an index visible/invisible without rebuilding it.
If you've meant that you want to avoid dropping the unique index, then please read Bill Karwin's answer, which properly describes that it's not possible.
However, if you've meant that you want to recreate an index without dropping and recreating the table, then it's certainly possible, like:
DROP INDEX indexname on tablename;
and then
CREATE UNIQUE indexname ON tablename(columnname);
I have few columns in various tables of MYSQL database which were allocated more length than actually needed. So now I try to make them of proper length. They were VARCHAR(64) and I want to make them CHAR(36). Those columns are involved in Foreign Keys. These changes are going to be a new SQL file, which is run with Flyway Engine. Which of the two options is better?
1) drop the constraints and modify columns and recreate constraints.
2) execute set foreign_key_checks=0, alter columns and execute set foreign_key_checks=1.
Since you are going to change the length its better to disable foreign_key_checks. Because it will affect only your current session (unless you mention global). so that it will not affect other session which depends on foreign key.
Some databases, like MySQL [1] and PostgreSQL [2], support bundling of certain compatible ALTER TABLE statements (as non-standard SQL).
For example we can have:
ALTER TABLE `my_table`
DROP COLUMN `column_1`,
DROP COLUMN `column_2`,
...
or
ALTER TABLE
MODIFY `column_1` ... ,
MODIFY `column_2` ... ,
instead of having individual statements:
ALTER TABLE `my_table` DROP COLUMN `column_1`;
ALTER TABLE `my_table` DROP COLUMN `column_2`;
or
ALTER TABLE `my_table` MODIFY `column_1` ... ;
ALTER TABLE `my_table` MODIFY `column_2` ... ;
etc
For comparison of the same feature, PostgreSQL [2], which also implements this, will perform all operations in a single scan:
The main reason for providing the option to specify multiple changes in a single ALTER TABLE is that multiple table scans or rewrites can thereby be combined into a single pass over the table.
Although for DROP COLUMN specifically it will often not even need do that:
The DROP COLUMN form does not physically remove the column, but simply makes it invisible to SQL operations...
Questions:
Would the multi-column statement result in traversing all the rows just once and performing all changes needed?
How does MySQL actually perform DROP COLUMN? Does it also "hide" the columns first, or does it delete the data straight away?
Assumptions:
Using InnoDB
No indexes/complex defaults are involved in any of the columns we want to change/drop (so basically changes that would not require a temporary table when run as individual alter statements)
References:
[1] MySQL ALTER TABLE docs
[2] PostgreSQL ALTER TABLE docs
MySQL's InnoDB:
(This does not really answer the Questions, but provides a little more insight in the the bigger question of ALTER.)
If any of the alters needs to copy the table over, you are probably better off putting all alters into the same statement. Changing the PRIMARY KEY, for example, requires rebuilding the data that is clustered with the PK.
Some alters can be achieved by simply altering the schema; these are virtually instantaneous, and could be done via separate alter statements. Adding an option to ENUM was implemented long ago.
Some alters need some form of scan, but can do it "in the background". DROP INDEX can be done by quickly "hiding" it, then freeing up the BTree in the background.
I have left out a grey area in which you batch 'simple' alters. One would hope that ALTER is smart enough to simply go through them quickly, rather than deciding to copy the table over.
I got some useful feedback but decided to respond to my own question to provide a more concrete set of answers.
Would the multi-column statement result in traversing all the rows just once and performing all changes needed?
Yes, if the alter statement results in rebuilding the table then it only needs to do it once.*
* This answer comes from my own testing and other mostly anecdotal evidence (including #Uueerdo 's in this post). It would be useful to have some official docs for this...
How does MySQL actually perform DROP COLUMN? Does it also "hide" the columns first, or does it delete the data straight away?
MySQL will rebuild the table in place (rather than create a copy or just change metadata) for most column operations. Each specific case can be found in the Online DDL docs for InnoDB.
A few operations like renaming a column or setting a default value will just alter metadata, so they don't require a table rebuild.
However, dropping a column DOES require a full table rebuild.
From the docs:
An ALTER TABLE statement that contains DROP INDEX and ADD INDEX
clauses that both name the same index uses a table copy, not Fast
Index Creation.
This is a bit unclear to me. Is it talking about the NAME of the index? Can someone give an example of a query in which MySQL resorts to a table copy?
Indeed, it sounds like this line is about:
An (One, single) ALTER TABLE statement
that contains (both) a DROP INDEX and an ADD INDEX clause
and both clauses name the same index
and states that such a statement uses a table copy, not Fast Index Creation.
Such a statement would be:
ALTER TABLE MyTable
DROP INDEX MyIndex
ADD INDEX MyIndex(MyColumn);
The documentation is not really clear about the reason behind this, but I think the database want to create an index first and then drop the other index, so the statement by itself can more easily be made atomic. (Creating the index might fail.) If the index name itself is used in the storage as well, that order of first creating then dropping would give a conflict.
After all, fast index creation is a relatively new feature, so they might improve this over time.
I saw some other questions related to this, but they were not MySQL.
The database is a live database, so I don't want to delete and recreate the table. I simply want to make a column no longer unique, which is less permissive in nature so it shouldn't cause any problems.
If your column was defined unique using UNIQUE clause, then use:
ALTER TABLE mytable DROP INDEX constraint_name
, or, if your constraint was implicitly named,
ALTER TABLE mytable DROP INDEX column_name
If it was defined unique using PRIMARY KEY clause, use:
ALTER TABLE mytable DROP PRIMARY KEY
Note, however, that if your table is InnoDB, dropping PRIMARY KEY will result in implicit recreation of your table and rebuilding all indexes, which will lock the table and may make it inaccessible for quite a long time.
These are instructions for phpmyadmin app (if you are using phpMyAdmin) ::
In a some cases, the developer (you) may not want to drop it but rather just modify the "uniqueness" to "not-unique".
Steps :
Go to the table in context, where you want to make the modification
Click on the "Structure" tab (mostly next to Browse)
Look for the "+Indexes" link, just under the columns. Yeah... now click it
Now you can see all the "Indexes" and you can now click on the "DROP" button or link to modify.
Answer was found here :
Source : https://forums.phpfreaks.com/topic/164827-phpmyadmin-how-to-make-not-unique/
Just DROP the unique index. There shouldn't be a problem with the fact that it is a live DB. If it is a really large table, you may block some queries temporarily while the index is removed. But that should only happen if you were adding an index.
ALTER TABLE table_name DROP INDEX index_name;
Although the accepted answer is incorrect (see comments), the suggested workaround is possible. But it is not correct too, at least for a "live table", as asked.
To lower the impact you should create a new index at first, and then delete the old one:
ALTER TABLE mytable ADD INDEX idx_new (column);
ALTER TABLE mytable DROP INDEX idx_old;
This avoids using the table (column) without index at all, which can be quite painful for clients and the MySQL itself.
MySQL requires indexes on foreign keys and referenced keys so that foreign key checks can be fast (MySQL Manual).
If the unique key that you want to make non-unique is used by a foreign key constraint, then you'll get an error when dropping it. You will have to recreate it on the same line:
alter table mytable drop KEY myUniqueKey, add key myUniqueKey (myColumn);