MySQL 8.0.29.
So I've put the following in my configuration:
[mysqld]
innodb_ft_min_token_size=2
ft_min_word_len=2
Rebooted my server.
Rebuilt the Table Indexes with:
ALTER TABLE t1 ENGINE = InnoDB;
And MATCH AGAINST still refuses to return records with 2-letter names, like "Ed Snow".
If I do MATCH AGAINST('ed') or AGAINST (+ed) OR (+ed snow) IN BOOLEAN MODE even though we have hundreds of people named "ed" in our databse... nothing comes up.
The column I'm matching against is a FULLTEXT name_full column like 'ed snow','ed smith', 'ed lindsky', etc.
Any ideas?
Related
If that makes a difference, here are my server data:
SQL version: 10.3.35-MariaDB - MariaDB Server
Database tool: phpMyAdmin 4.9.7
I have a table called phpbb_posts. It's a huge table with 17 949 entries, with the primary key named post_id, reaching 46302.
I also have a small plaintext *.sql file which holds only a small number of these entries, 749 of those. It's a typical exported file from phpMyAdmin that got various edits. What I want to do now, is to replace the entries on the database with the ones from the file, without changing the primary key or any duplicates.
For the sake of simplicity I made a smaller version of the file with just two entries in there if some other data in there has meaning. I just removed most of the entries themselves, schema is not changed:
https://pastebin.com/ctnqKgkM
The database already holds posts with ID 46182 and 46187 (and many many more).
I know there is a possibility to just do this:
INSERT INTO table (column_names)
VALUES (data)
ON DUPLICATE KEY UPDATE
column1 = expression, column2 = expression…;
and I've used that sometimes, but completely rewriting the export.sql file manually with the column1=value, column2=value etc. is not an option, it holds hundreds of entries and it would take me dozens of hours to do that.
Is there any other option to do the trick?
I am using a FullText index on MySQL v5.6 InnoDB table.
and running this query to perform search on the table
SELECT * FROM `table` WHERE MATCH(title,desc) AGAINST ('+hello -for' IN BOOLEAN MODE);
when i run the above query it still gives me the results which includes word for in the title or desc.
I have already made the following changes in my my.cnf file to avoid stopwords.
innodb_ft_min_token_size=2
ft_min_word_len=2
ft_stopword_file = ""
Why i am still getting results with word for included in it?
You need to ensure that the server variable innodb_ft_enable_stopword is set to OFF if you aren't wanting to use stop words at all.
SET ##SESSION.innodb_ft_enable_stopword = 'OFF';
When I execute SELECT * FROM table, the returned rowset does not contain all of the columns in the table. It does not contain the columns that were recently added. Though, the structure tab in phpMyAdmin shows the new columns. And if I query directly like SELECT new_column_name FROM table, the column values also do appear.
This problem is present both if I query the table via PHP or phpMyAdmin.
Interesting enough, if I run SELECT *, new_column_name FROM table, the new_column_name values are duplicated.
What might the reason for such weird behaviour, and how do I restore the default behaviour showing all columns using *?
UPDATE:
I have flushed the table cache and I have restarted the mysql server, but nothing changes.
UPDATE:
Storage engine is InnoDB
UPDATE:
Before adding new columns, I drag-and-dropped a column header to another place to switch the columns' places. But after adding the columns, I clicked restore column order, so it shouldn't have had any influence...
UPDATE:
After checking what is returned if I run the query via command-line, I now see that the problem is actually only with phpMyAdmin (the command line returns the new columns among others). Double-checking what I was doing in PHP showed that I was explicitly selecting specific columns. So, now the problem persists only in phpMyAdmin. What might be wrong with it?
Had this problem just now.
Fixed it by changing the Storage Engines from InnoDB to MyISAM, then back to InnoDB again.
I'm building a search for a site, which utilizes a fulltext search. The search itself works great, that's not my problem. I string together user provided keywords (MATCH... AGAINST...) with AND's so that multiple words further narrow the results. Now, I know that certain stop words aren't indexed, and that's fine with me I don't really want to use them as selection criteria. But, if a stopword is provided in the keyword set (by the user), it kills all the results (as expected) even if the word actually is in a certain text block.
My question: is there any way to check to see if a certain word is a stop word at the time of the query? My preferred solution would just be to exclude the relevant word from the search criteria (I don't care if a user can narrow results by the word 'neither', I just don't want MySQL to return an empty result set because the user provided it, even though neither does exist in the results). Or, am I just going to have to empty the stopword list? Thanks very much for any help.
edit ----
I'm sorry, but there's really no code snippets to provide for this one. The code works fine, actually exactly as expected. It's more of a logical problem I'm dealing with. But as an example, in the way of explanation:
lets say there are three records, which include the words (but are not limited to)
1: apple, orange, mango, banana
2: grape, orange, pineapple, mango
3: potato, mango, melon, keira knightly
If the search word entered by the user is mango, all results are returned correctly. If the words are orange AND mango, results 1 and 2 are returned (correctly). Now, let's say banana is a stop word (it's not... but let's assume it is), if the search is for orange, mango, AND banana, no results are returned (because banana isn't in the fulltext index).
What I'm looking for is if anyone else has encountered this problem, and has a way to work around it. Sort of an:
if 'banana' NOT STOP WORD match 'banana' against `words`. (OBVIOUSLY not real code).
Or... am I just going to have to drop the stopword list...
You can verify the keywords by comparing all stopwords. Here is the list of stopwords
I've found out a solution to disable stopwords from fulltext.
You just need to locate .cnf file and add this,
ft_stopword_file = ""
restart mysql engine and rebuild indexes;
Hope this work
How to disable fulltext stopwords in MySQL:
In my.ini text file (MySQL) :
ft_stopword_file = "" or link an empty file "empty_stopwords.txt"
ft_min_word_len = 2
// set your minimum length, but be aware that shorter words (3,2) will increase the query time dramatically, especially if the fulltext indexed column fields are large.
Save the file, restart the server.
The next step should be to repair the indexes with this query:
REPAIR TABLE tbl_name QUICK.
However, this will not work if you table is using InnoDB storage engine. You will have to change it to MyISAM :
ALTER TABLE t1 ENGINE = MyISAM;
So, once again:
1. Edit my.ini file and save
2. Restart your server (this cannot be done dynamically)
3. Change the table engine (if needed) ALTER TABLE tbl_name ENGINE = MyISAM;
4. Perform repair REPAIR TABLE tbl_name QUICK.
Be aware that InnoDB and MyISAM have their speed differences. One read faster, other writes faster ( read more about that on the internet )
disable stopword for fulltext search in mysql using this steps
1: open my.ini file in mysql
2: place below two line after [mysqld] line in my.ini (search [mysqld] in file)
ft_min_word_len=1
ft_stopword_file=""
3: restart your server
4: repair your table using below command
> repair table tablename;
5: now your search is working....
For the INNODB case, it is possible to disable stop_words when you create the index.
SET ##SESSION.innodb_ft_enable_stopword = 'OFF';
create table foo
....
fulltext (search_col)
This will cause the full text index to be created with the stopwords disabled. You can verify by using the following queries.
SET GLOBAL innodb_ft_aux_table = 'schema/foo';
select * from information_schema.innodb_ft_config;
Your results will look like this:
Notice that use_stopword is set to 0.
Search for use_stopwords on this mysql documentation page.
and Checkout innodb_ft_enable_stopword here
setting
ft_stopword_file = ""
didn't work for me, I'm using INNODB tables and MySQL 5.6 (stop words still not indexed in full text indexes after optimizing associated table)
this solution works (even if you are not super user) :
CREATE TABLE mydb.stopwordslist(value VARCHAR(20)) ENGINE = INNODB;
INSERT INTO mydb.stopwordslist(value) VALUES ('skipthisword');
for all users but you still need super user rights :
SET GLOBAL innodb_ft_server_stopword_table = 'mydb/stopwordslist';
for just the user (assuming it the one who recreating indexes and updating columns)
SET SESSION innodb_ft_user_stopword_table = 'mydb/stopwordslist';
as it is a session variable, it won't last when your session is closed so please make sure you set it at each session or before you optimize or insert into tables having fulltext index or when you update column indexed by fulltext index
try using MATCH…AGAINST…IN BOOLEAN MODE
Like this one:
WHERE MATCH(author,title)
AGAINST('"origin of"' IN BOOLEAN MODE);
I connect with user "root" onto my database "test" which I host locally for development. Among others I have the table "ratingcomment". For some reason when I click on the table "ratingcomment" phpMyAdmin shows me the following error:
Fehler
SQL-Befehl:
INSERT INTO `phpmyadmin`.`pma_history` (
`username` ,
`db` ,
`table` ,
`timevalue` ,
`sqlquery`
)
VALUES (
'root', 'test', 'ratingcomment', NOW( ) , 'SELECT * FROM `ratingcomment`'
)
MySQL meldet:
#1062 - Duplicate entry '838' for key 'PRIMARY'
I used google to finde out the following
"This indicates that you have a UNIQUE or PRIMARY index on a table, and there is a duplicate value someone on one of the values in one of these indexes."
But I still dont quite understand the error! I use a primary Key, which auto-increments for all of my tables, so there actually shouldnt be a problem with the table. I had another table named "rating" which had a column "comment". Can it be, that this causes problems?
Quick fix:
REPAIR TABLE `phpmyadmin`.`pma_history`
If that fails, I'd just truncate/empty the table.
TRUNCATE TABLE `phpmyadmin`.`pma_history`
Although phpmyadmin has it's place in my toolbox, I personally don't use it's internal db.
ADDENDUM
MyISAM tables can easily become corrupted. A couple causes that usually hit me: if the MySQL is not shutdown properly, or if the table has a FULLTEXT index and the stopword file on disk had changed.
Simply stated, the REPAIR just checkes the data file for errors (and depending on your options, makes it usable again) and rewrites the index file. Fair warning: with MyISAM, repairing a table can often toast all your data in that table to make it usable. See doc for more details.
A google search pertaining to this pma table being corrupted lead me to this.
This appears to be an internal error. You've issued this query:
SELECT * FROM `ratingcomment`
phpMyAdmin tries to write such action in its internal event log and it fails. If you Google for pma_history you'll find several references to such table being corrupted.
My advice is that you find another SQL client (such as HeidiSQL) and try to repair the phpMyAdmin database.
I know this is kinda late but I had the same problem and wanted to share what I did.
In PhpMyAdmin, I went to the table's Operation tab, and just incremented the AUTO_INCREMENT value under Table options and inserted a dummy record.