I get an error #1283 - Column 'title' cannot be part of FULLTEXT index when I try to include the columns I want to alter via FULLTEXT in my database.
ALTER TABLE users ADD FULLTEXT (`firstname`, `lastname`, `title`, `description`)
I'm not understanding why this error shows or how to go about in fixing this problem. Would be grateful for any ideas or tips.
NOTE: This post applies to old version of MySQL. Starting from
version 5.6, INNODB supports FULLTEXT index and the below code should not be used. Leaving the original answer for reference.
FULLTEXT index works only on MyISAM tables, not on InnoDB. You can check what storage enging you use by typing:
SHOW CREATE TABLE users;
then, you could ALTER the table to use MyISAM engine using this command:
ALTER TABLE users ENGINE = MyISAM;
Starting from Mysql 5.6, INNODB now supports FULLTEXT INDEX. Now I also ran into this issue when adding FULLTEXT to a table of mine and ran into multiple issues.
you need to insure your ibdata1 file is set to autoextend. http://dev.mysql.com/doc/refman/5.0/en/innodb-data-log-reconfiguration.html
I was running out of diskspace. While mysql alters a table, mysql uses tmp data and memory to do so. You need to make sure your tmp dir in you cnf file is pointing to a directory with enough space. Also, since it uses memory, it will use your Virtual Memory. Meaning your OS drive needs to have enough space. If this is not an option, create a tmp duplicate tmp table and alter that table with the fulltext and right an INSERT INTO table SELECT * FROM og_table
If your table is InnoDB then you can not use it. And need to drop it.
You can also refer to limitations of InnoDB # http://dev.mysql.com/doc/refman/5.5/en/innodb-restrictions.html
INNODB supports FULLTEXT INDEX since Mysql 5.6
To avoid errors "Column * cannot be part of FULLTEXT index"
check TEXT INCODING of your columns ;) It must be the same.
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.
In PostgreSQL, we can search table based on full text search like this -
SELECT title
FROM pgweb
WHERE to_tsvector('english', body) ## to_tsquery('english', 'friend');
Source - http://www.postgresql.org/docs/current/static/textsearch-tables.html
How can we do similar search in MySQL 5.5 which is quite easily done in PostgreSQL?
You probably want MySQL's full text search functionality. Essentially you create a FULLTEXT index then search against it using MATCH() ... AGAINST.
I'm not aware of a facility to set the search language per-query in MySQL, but that doesn't mean no such support exists. It wasn't clear if per-query language settings were a requirement for you.
The latest stable release of MySQL supports full text search on the modern transactional and crash-safe InnoDB table type as well as the unsafe MyISAM table type. If your MySQL only does FTS on MyISAM it's time to upgrade. 5.6 supports full text search on InnoDB.
Alternately, if you really can't upgrade, you can store your important data in InnoDB tables and run a periodic query to update a MyISAM table you use as a materialized view for fulltext search only:
Create a new MyISAM table
INSERT INTO ... SELECT the data from the InnoDB table into the new MyISAM table
CREATE the fulltext index on the new MyISAM table
DROP the old MyISAM table you were using for fulltext indexing; and
finally ALTER TABLE ... RENAME the new MyISAM table to have the name of the old one.
You'll have a very short window during which the fulltext index is unavailable between when you drop the old table and re-create the new one. Your data also gets out of date and stale between view refreshes, though it's possible you can work around that with triggers (I don't use MySQL enough to know). If you can't live with these limitations, upgrade to 5.6.
MySQL's full text search offers control of stopwords and other tuning. It's a solid offering that should do the job nicely.
Actually, I would like to switch the engine of my tables. There are in InnoDB and I want to set them to MyISAM because of this
ALTER TABLE `xxx_db`.`yyy` ADD FULLTEXT `ft_modele` (
`anno_modele`
)
Error :
Documentation
#1214 - The used table type doesn't support FULLTEXT indexes
So... I do this :
ALTER TABLE `annonce` ENGINE = MYISAM
But I have an error too :
#1217 - Cannot delete or update a parent row: a foreign key constraint fails
I understand the error... but I don't really want to kill all my references index, and re-create them. Too long.
Someone has an idea to convert innoDB to MyISAM ? I read that fulltext is supported for MySQL 5.6.4 ... unfortunately I have 5.5.28 and I'm on Plesk 11. I fear if I do an upgrade, my server crashs.
Someone can help me ?
Fulltext indexes or foreign key constraints (MyISAM does not support those) you can only chose one (until MySQL 5.6 that is).
Changing database engine will result in total table rewrite (creating a new one, moving data, dropping the old one) anyway.
If I were you, I would go for the upgrade.
Unfortunately you can't have a table in MySQL 5.5 that supports both foreign key constraints and fulltext indexes. As you've already noted MySQL 5.6 does support fulltext indexes for InnoDB.
I recommend updating MySQL if possible. MySQL 5.6 is stable.
Alternatively use an external full text index like Sphinx or Lucene
Unformtunately, there is no good option for me. While there is not an upgrade for plesk with the new version of mysql, i can't upgrade the server without create instability.
So, I just mysqldump my database and edit tables and keys.
Tank for the help. Have a nice day
I have a myisam only dedicated 32 GB RAM mysql server that is running on default configuration. I want to change the engine type to InnoDB of one table in order to avoid table locks. It has 50 million records and size on disk is around 15 GB. I am using mysql version 5.5
I guess I will need to add the following options and restart mysql.
innodb_buffer_pool_size=1G
innodb_log_file_size=100M
innodb_file_per_table=1
What else is considered to be necessary while changing the engine type?
You'll actually be running a command to convert each table.
It goes faster to first sort the table:
ALTER TABLE tablename ORDER BY primary_key_column;
Then, run the alter command:
ALTER TABLE tablename ENGINE = INNODB;
It might take a while if the table is really large, and it will use a lot of your CPU....
First of all check if your database supports InnoDB engine (I bet it is supported ;)):
SHOW ENGINES\G
If so, there is already default innodb related parameters in place, check them with:
SHOW VARIABLES LIKE '%innodb%'
and try to understand them and alter the to your specific needs. Even if you use the default params, you are now fine to play arround with InnoDB tables.
If you want to create only InnoDB tables, you can change your default storage engine, either for your current session with: SET storage_engine=INNODB; or in your config using default-storage-engine option.
By the way, the fastest way to convert a table to InnoDB is not the above described way. One can do the following to convert a table to InnoDB by simply inserting the data:
CREATE TABE new AS SELECT * FROM old WHERE 1<>1;
ALTER TABLE new ENGINE = INNODB;
INSERT INTO new SELECT * FROM old;
Of course you have to add the indexes you need manually, but its usually worth the time (and pain) you save compared to the ALTER TABLE ... on slightly bigger tables.