on my table I have 3 different FULLTEXT indexes like so:
FULLTEXT KEY `product_name` (`product_name`,`product_description`),
FULLTEXT KEY `product_brand` (`product_brand`,`metal_type`,`primary_stone`,`product_type`,`product_type_sub`,`product_series`),
FULLTEXT KEY `primary_stone_sub` (`primary_stone_sub`)
This is because I added them after the fact like so:
ALTER TABLE cart_product ADD FULLTEXT(columnA, columnB);
Q1 How can I merge these 3 into 1 FULLTEXT index?
Q2 Also, so this doesn't happen again, how would I add a FULLTEXT column to the already existing FULLTEXT index?
Thanks!!!
It seems like you only want to have 1 FULLTEXT index, containing all of those columns. Is that right? You can also have several FULLTEXT indexes on this table, one containing all of the columns and others containing a subset. It all depends on your usage.
Just remember this caveat from the manual and make sure your fulltext index column list(s) match the columns you are querying against exactly:
The MATCH() column list must match exactly the column list in some FULLTEXT index definition for the table, unless this MATCH() is IN BOOLEAN MODE. Boolean-mode searches can be done on nonindexed columns, although they are likely to be slow.
The answer to both questions is that you need to drop the existing index and recreate it with an updated list of columns:
ALTER TABLE cart_product
DROP INDEX `product_name`,
DROP INDEX `product_brand`,
DROP INDEX `primary_stone_sub`,
ADD FULLTEXT INDEX `cart_product_fti` (
`product_name`,
`product_description`,
`product_brand`,
`metal_type`,
`primary_stone`,
`product_type`,
`product_type_sub`,
`product_series`,
`primary_stone_sub`
);
Related
I am working on a database with large number of rows (6 Mil+).
This table has a composite primary key on two columns.
It also has separate index on each of those fields as there are queries that require this. Obviously, one of those indexes (indices?) is redundant and slowing down performance for write operations.
How do I find out which one is redundant? I understand the first column of a primary key is already indexed and need not be indexed separately. Is that correct? If so, is there a query I can run to find out which is the first one in the list?
SHOW INDEXES FROM tablename will include a Seq_in_index column, which tells you which is first (aka, left most) column, second column, etc.
Therefore, whichever column is listed with a value of 1 for Seq_in_index is the column that does not need it's own single column index.
You can also use SHOW CREATE TABLE tablename to see the index listed from left to right, and that order displayed correctly represents the order of columns in the index.
SHOW CREATE TABLE tablename gives you all the indexes, in their established order.
You don't need INDEX(a) because the column(s) in it are the first column(s) in the INDEX(a,b),
That applies to INDEX / UNIQUE / PRIMARY KEY in (a,b).
I understand the first column of a primary key is already indexed
Erm, no. All the columns in the primary key are indexed.
An explanation of how indexes work is stretching the scope of a post here, and the question of which indexes to put on your table is way too broad.
Suppose you have a primary key defined on attributes a,b,c. This index can be used for queries with predicates
a
a and b
a and b and c
But (at least, the last time I checked) it would not be used for a query with predicates
b
b and c
The optimizer will only ever use one index for each table in a query.
The right indexes depend on the volume of data, the cardinality of the data and the frequency and combination of predicates in your queries. There are execution and storage overheads when you start adding indexes, even just for select operations badly designed indexes can make your query slower than it would run without indexes.
I have a table where two columns are used in a where condition.
This is a MyIsam table and both columns hold text and use FULLTEXT as index.
The values in both columns are not unique.
The select statement works pretty slow.
Question is: can I simply remove the FULLTEXT index and use another index instead?
The query that is used is just as simple as possbile:
SELECT * FROM tbl WHERE col1=X AND col2=y and col3=z
Thanks!
ALTER TABLE `tableName` DROP INDEX `indexName` ,
ADD INDEX `indexName` ( `ColName` )
This shuld remove the old "FULLTEXT" index and add a "NOT FULTEXT" index.
I am creating a mysql fulltext search engine for my website, and I have an advanced search page that allows the user to limit which columns they would like to search under. However, whenever I make a fulltext search index, all the columns used in that index must be used or else I get an error message. Is there any way to make a mysql index for fulltext where I can use just some of the columns?
For example I have 5 columns in my index, made by this statement:
ALTER TABLE table1 ADD FULLTEXT fulltext_index(subject, course, prof, semester,
year);
If I wanted to search under only subject and course, I would get the error:
#1191 - Can't find FULLTEXT index matching the column list
You just need to create more indexes for each possible combination you want to search:
alter table table1 add fulltext fulltext_index2(subject,course);
alter table table1 add fulltext fulltext_index3(course,semester,year);
Etc...see if that solves the issue.
No, a fulltext index requires you to use all of the columns. If you want to use only some of them, you'll need a separate fulltext index for every permutation. I haven't tested it, but you MAY get around it by using only columns in the order specified. e.g. an index on columns (a,b,c) might allow you to search only (a,b) because they're listed first, but not (a,c) or (b,c).
I'm trying to set up a FULLTEXT index in an existing db table (with like 50k records), with the command below, which worked:
ALTER TABLE `record_attributes` ADD FULLTEXT `FULLTEXT` (`content_text` ,`content_varchar`)
Problem is, when I try to do a MATCH AGAINST on that table, it gives me this error:
#1191 - Can't find FULLTEXT index matching the column list
I've been searching on google and didn't find anything that I could be doing wrong. Does the index have to be added on tables without any records?
Cheers
If you search by 1 column, fulltext index by 2 columns is not matching.
I'm creating tables using phpMyAdmin and want to define two different columns as indices. I'm not trying to create a multi-column index but phpMyAdmin creates them as such. Are there any possible issues with that? The fields don't relate to each other directly and both fields will not be used in WHERE clauses simultaneously.
Consider:
ALTER TABLE `documents` ADD INDEX (`offer_number`, `contract_number`);
And:
ALTER TABLE `documents` ADD INDEX (`offer_number`);
ALTER TABLE `documents` ADD INDEX (`contract_number`);
What's the difference?
MySQL can only make use of an index if the first column(s) of the index match the columns used in the query. In other words, if you perform a query where an index on contract_number could be used, the composite index won't be used since contract_number is not the first column in that key. The composite index could be used for a query where offer_number is used, however.
http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html
http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html
Given what you say about these fields, they should not be a part of one multi column index.
If you want to create single column indexes on PhpMyAdmin, you need to create them one at a time.