I have a table in MYSQL database that is about 45GB and my disk available space is 30GB. The table type is MyISAM and MySQL version is 5.6. I want to create FULLTEXT on two columns of the table called name and text where name is varchar(255) and text is longtext.
Will MYSQL create temporary table of about the same size as the size of the table ( 45GB) when creating index?
Which is better to use:
ALTER TABLE ADD FULLTEXT or CREATE FULLTEXT INDEX in above context?
The two commands are the same (one maps to the other). It will make a full copy of the table with all its new indexes. So, it is impossible since you have less free disk space than even the table size.
Get bigger machine? Remove other stuff? Do other cleanup?
Note further, the FT index may be close to 45GB, itself. So, even if you could create the index, it might overflow your 30GB.
InnoDB's FULLTEXT seems to create a much smaller index. But still, converting to InnoDB cannot be done without more than 45GB free space.
Related
If I change innodb_ft_min_token_size =1 from default of 3, will this cause a lot more disk usage? Any performance issues with search?
I want to be able to use fulltext search in 1 character in words.
Also once I make this change how would I rebuild the index? Will this put a lot of load on server?
There are not that many 1- and 2- letter words, so the space change may not be that great.
Modifying innodb_ft_min_token_size, innodb_ft_max_token_size, or ngram_token_size [in my.cnf] requires restarting the server.
To rebuild FULLTEXT indexes for an InnoDB table, use ALTER TABLE with the DROP INDEX and ADD INDEX options to drop and re-create each index.
-- https://dev.mysql.com/doc/refman/8.0/en/fulltext-fine-tuning.html
The "Scope" of innodb_ft_min_token_size is "Global". That is, it applies to all InnoDB FT indexes.
-- https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_ft_min_token_size
Recreating the index will read the entire table and rebuild the FT index, which will "lock" the table at some level for some period of time. The time to rebuild will be roughly proportional to the size of the table. And it will consume a bunch of extra disk space until it is finished. (The table and all the indexes will be copied over and at least the FT index will be rebuilt.)
If you have a thousand rows, no big deal. If you have a billion rows, you will need a long "downtime".
After changing the innodb_ft_max_token_size, I would be afraid to do a short wildcard test like
AGAINST('a*' IN BOOLEAN MODE)
If you have a test server, simply try it.
I noticed that the documentation recommends a value of 1 for Chinese, etc.
Can it used to repair mysql index. I am facing performance issues even for queries that use index
Depends on your version of MySQL and storage engine but in general:
OPTIMIZE TABLE Analyzes table, stores the key distribution for a table, reclaims the unused space and defragments the data file.
ANALYZE TABLE Only analyzes table and stores the key distribution.
https://dev.mysql.com/doc/refman/5.6/en/analyze-table.html
I have a MySQL table with 66 million rows and want to add a full-text index to a varchar(255) column in that table.
Is there a time-to-execute calculator or a formula that I can use to work out how long it will take to create this index?
I know that server specs will impact this so let's say an appropriately sized server for the DB.
EDIT: I do not have access to this database and the only chance I will have to add this index is during a production switch-over so there's no possibility to test this with a subset of rows.
I have a MySQL table that has 165,716 records (and counting). The table is 233,3 MB large. Now I want to add a FULLTEXT index to a column in that table. Is that possible, or is it going to be a problem?
Kind regards
It's possible if the table is running the MyISAM engine, but it's likely to take a long time to complete the initial indexing.
[edit]I misread the size - I thought it was 2.3GB, not 233MB! If that's the case, the indexing shouldn't take that long.
Suppose that I have two tables stuff and search_index. For various reasons I would prefer to generate a custom index table with schema along the lines of the following.
I believe that this has to be a separate table as it would require MyISAM storage engine for FULLTEXT support. All of my other tables are InnoDB for transaction support.
search_index (MyISAM):
-----------------------
stuff_id BIGINT PRIMARY
keywords TEXT FULLTEXT ; Not same as text in `stuff`
; (optimised & space delimited)
How often should search_index table be updated:
Whenever stuff records are created or updated.
Periodically scan "dirty" stuff records and update search_index accordingly.
Other...
My view is that the benefit of 1 would be easier to maintain and search becomes effective immediately but with an immediate re-index in database. 2 would not be as effective but all reindexing can happen in one hit. Is this true?
How efficient is MySQL at inserting/updating records that have FULLTEXT indexing?
Additional Note: I am trying to keep the schema as portable as possible (different rdbms drivers with PDO)