I'm trying to use fulltext and match against multiple tables but without Join because they are not related.
I've tried something like:
SELECT mg_users.username, mg_users.email, mg_uzgajivac.imeuzgajivaca ...
FROM mg_users,mg_uzgajivac,mg_buy_it_now,mg_golu ...
WHERE MATCH(mg_users.username) AGAINST ('rasa')
OR MATCH(mg_users.email) AGAINST ('rasa')
OR MATCH(mg_uzgajivac.imeuzgajivaca) AGAINST ('rasa')
OR MATCH(mg_uzgajivac.mjesto) AGAINST ('rasa') ...
But it returns nothing, I'm not sure what I'm doing wrong.
I think your issue is that the indexes are not up to date. You need to rebuild your indexes for MATCH ... AGAINST to work correctly.
If you are using MyISAM tables then repair the tables will rebuild you the indexes
REPAIR TABLE table_name;
But if you are using Innodb tables "and you should." You can execute a fake ALTER command which will force the indexes to be rebuild. It will not change anything but it will force the table to rebuild.
ALTER TABLE table_name ENGINE=innodb;
This may be off-topic but it is something to think about. You can use a multiple column fulltext index to make your query a bit faster
ALTER TABLE mg_users ADD FULLTEXT INDEX (user_name, email);
ALTER TABLE mg_uzgajivac ADD FULLTEXT INDEX (imeuzgajivaca, mjesto);
Then your query will look like this
SELECT mg_users.username, mg_users.email, mg_uzgajivac.imeuzgajivaca ...
FROM mg_users,mg_uzgajivac,mg_buy_it_now,mg_golu ...
WHERE MATCH(mg_users.username, mg_users.email) AGAINST ('rasa')
OR MATCH(mg_uzgajivac.imeuzgajivaca, mg_uzgajivac.mjesto) AGAINST ('rasa')
...
Related
Background:
Hey I'm using MySQL 5.6.17 InnoDB, I've read on mysql website that FULLTEXT is now avaiable for InnoDB in 5.6+ version. so i don't have to change from InnoDB to MyISAM Here is the link I altered TWO of my table columns for FULLTEXT search by using the following query
ALTER TABLE `es_officers` ADD FULLTEXT Index_officer_name (es_officer_name)
ALTER TABLE `es_officers` ADD FULLTEXT Index_officer_fname (es_officer_fname)
Altered Table Registered in Information Schema:
Then i checked in my information schema if the altered table columns are registered or not by running the following query
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME
FROM statistics
WHERE index_type LIKE 'FULLTEXT%'
It showed me exacttly two results which i was expecting
Problem:
when i write a query to MATCH a sting AGAINST two columns it gives me an error
SELECT * FROM `es_officers` WHERE MATCH (es_officer_name, es_officer_fname) AGAINST ('abc')
#1191 - Can't find FULLTEXT index matching the column list
BUT:
when i try to query the columns separately like below it works absolutely fine
SELECT * FROM `es_officers` WHERE MATCH (es_officer_name) AGAINST ('abc')
SELECT * FROM `es_officers` WHERE MATCH (es_officer_fname) AGAINST ('abc')
I don't know what is it I'm doing wrong, help is highly appreciated.
Multiples issues:
You have two separate fulltext indexes, each covering a single field. You have WHERE MATCH (es_officer_name, es_officer_fname) as your query, which requires a SINGLE index covering both fields. MySQL will not use two separate indexes for this query - it can't. that's not how fulltext indexing works. You need an alter ... fulltext (es_officer_name, es_officer_fname) instead added.
And even then, abc will fall under the default minimum word length and won't get indexed.
Besides, you can try something like:
SELECT * FROM es_officers
WHERE MATCH es_officer_name AGAINST ('abc') + MATCH es_officer_fname AGAINST ('abc')
Though, as Marc B said, 'abc' value is too short.
I'm using SugarCRM and a few weeks ago I executed a a query on MySQL which created an index to prevent duplicate rows. Where can I see that or find it and edit or delete this ? I'm not able to remember the exact query but it's needed to add more columns. Using MySQL only just a few weeks.
MySQL error 1062: Duplicate entry 'example-dyplicate' for key
'idx_name'
To see the structure of a table, including all the indexes, use:
SHOW CREATE TABLE tablename;
You can delete an index with:
DROP INDEX indexname ON tablename;
There's no way to edit an index. If you want to change an index, you drop it and then add a new index with the new columns you want. However, you can do both in a single query using ALTER TABLE:
ALTER TABLE tablename DROP INDEX indexname ADD INDEX indexname (col1, col2, ...);
Is it possible to use the LIKE statement on ALTER TABLE similar to CREATE TABLE in MySQL?
Eg. 'CREATE TABLE db.tbl1 LIKE db.tbl2'
This clones a database table's structure. I want to alter an existing table with the same columns but to pick up the primary keys of another table.
I was thinking of something like 'ALTER TABLE db.tbl1 LIKE db.tbl2' but this throws back an error.
Any ideas?
Thanks
I required a similar thing and settled to use the following procedure:
ALTER TABLE tbl1 RENAME tbl1_old;
CREATE TABLE tbl1 LIKE tbl2;
INSERT INTO tbl1 SELECT * FROM tbl1_old;
DROP TABLE tbl1_old;
Altough this is not a single statement it should do the job. Only problem could be different index settings (UNIQUE, etc.) which cause errors when doing the "INSERT INTO" of the original table contents.
Everything ALTER TABLE can do is explained here.
As you can see importing indexes from another table is not mentioned. You could probably do that with some clever information_schema querying, but I don't think it would be worth the cost.
It seems you can't.
I have a table that has 170,002,225 rows with about 35 columns and two indexes. I want to add a column. The alter table command took about 10 hours. Neither the processor seemed busy during that time nor were there excessive IO waits. This is on a 4 way high performance box with tons of memory.
Is this the best I can do? Is there something I can look at to optimize the add column in tuning of the db?
I faced a very similar situation in the past and i improve the performance of the operation in this way :
Create a new table (using the structure of the current table) with the new column(s) included.
execute a INSERT INTO new_table (column1,..columnN) SELECT (column1,..columnN) FROM current_table;
rename the current table
rename the new table using the name of the current table.
ALTER TABLE in MySQL is actually going to create a new table with new schema, then re-INSERT all the data and delete the old table. You might save some time by creating the new table, loading the data and then renaming the table.
From "High Performance MySQL book" (the percona guys):
The usual trick for loading MyISAM table efficiently is to disable keys, load the data and renalbe the keys:
mysql> ALTER TABLE test.load_data DISABLE KEYS;
-- load data
mysql> ALTER TABLE test.load_data ENABLE KEYS;
Well, I would recommend using latest Percona MySQL builds plus since there is the following note in MySQL manual
In other cases, MySQL creates a
temporary table, even if the data
wouldn't strictly need to be copied.
For MyISAM tables, you can speed up
the index re-creation operation (which
is the slowest part of the alteration
process) by setting the
myisam_sort_buffer_size system
variable to a high value.
You can do ALTER TABLE DISABLE KEYS first, then add column and then ALTER TABLE ENABLE KEYS. I don't see anything can be done here.
BTW, can't you go MongoDB? It doesn't rebuild anything when you add column.
Maybe you can remove the index before alter the table because what is take most of the time to build is the index?
Combining some of the comments on the other answers, this was the solution that worked for me (MySQL 5.6):
create table mytablenew like mytable;
alter table mytablenew add column col4a varchar(12) not null after col4;
alter table mytablenew drop index index1, drop index index2,...drop index indexN;
insert into mytablenew (col1,col2,...colN) select col1,col2,...colN from mytable;
alter table mytablenew add index index1 (col1), add index index2 (col2),...add index indexN (colN);
rename table mytable to mytableold, mytablenew to mytable
On a 75M row table, dropping the indexes before the insert caused the query to complete in 24 minutes rather than 43 minutes.
Other answers/comments have insert into mytablenew (col1) select (col1) from mytable, but this results in ERROR 1241 (21000): Operand should contain 1 column(s) if you have the parenthesis in the select query.
Other answers/comments have insert into mytablenew select * from mytable;, but this results in ERROR 1136 (21S01): Column count doesn't match value count at row 1 if you've already added a column.
I have to delete about 10K rows from a table that has more than 100 million rows based on some criteria. When I execute the query, it takes about 5 minutes. I ran an explain plan (the delete query converted to select * since MySQL does not support explain delete) and found that MySQL uses the wrong index.
My question is: is there any way to tell MySQL which index to use during delete? If not, what ca I do? Select to temp table then delete from temp table?
There is index hint syntax. //ETA: sadly, not for deletes
ETA:
Have you tried running ANALYZE TABLE $mytable?
If that doesn't pay off, I'm thinking you have 2 choices: Drop the offending index before the delete and recreate it after. Or JOIN your delete table to another table on the desired index which should ensure that the desired index is used.
I've never really come across a situation where MySQL chose the wrong index, but rather my understanding of how indexes worked was usually at fault.
You might want to check out this book: http://oreilly.com/catalog/9780596003067
It has a great section on how indexes work and other tuning options.
As stated in other answers, MySQL can't use indexes, but the PRIMARY KEY index.
So your best option, if you have a PRIMARY KEY on the table is to run a fast SELECT, then DELETE according lines. Preferably in a TRANSACTION, so that you don't delete wrong rows.
Hence:
DELETE FROM table WHERE column_with_index = 0
Will be rewritten:
SELECT primary_key FROM table WHERE column_with_index = 0 => returns many lines
DELETE FROM table WHERE primary_key IN(?, ?, ?) => ? will be replaced by the results of the SELECTed primary keys.
If you have not that much lines to delete, it would be more efficient this way.
For example, I've just hit an exemple, on the same table, with the same data:
7499067 rows analyzed by DELETE : 12 seconds
vs
6 rows analyzed by SELECT using a good index : 0.10 seconds
0 rows to be deleted in the end