I have a modified stopwords list file, which basically took out the word 'alone'. I have updated my /etc/my.cnf
ft_stopword_file=/etc/new_stopwords_list.txt
After restarting my mysql server, I did the following to show that mysql is indeed picking up the new variable.
SHOW VARIABLES LIKE '%ft_stop%'
+------------------+-----------------------------+
| Variable_name | Value |
+------------------+-----------------------------+
| ft_stopword_file | /etc/new_stopwords_list.txt |
+------------------+-----------------------------+
Afterward, I did a REPAIR TABLE to update the index. However, when I do a search, the new setting does not seem to take effect. What am I doing wrong?
What mode are you using?. It could be because of the 50% threshold. Did you you check in this direction.
http://dev.mysql.com/doc/refman/5.0/en/fulltext-fine-tuning.html
Related
Okay, I understand what are errors and warnings in the context of MySQL. But what's the need of note-level warning? I have already searched the MySQL documentation but didn't find anything relevant. It would be better if someone could shed some light on the what are they and why they are useful.
mysql> create database if not exists city;
Query OK, 1 row affected, 1 warning (0.00 sec)
mysql> show warnings
-> ;
+-------+------+------------------------------------------------+
| Level | Code | Message |
+-------+------+------------------------------------------------+
| Note | 1007 | Can't create database 'city'; database exists |
+-------+------+------------------------------------------------+
1 row in set (0.00 sec)
I've always considered Note to be like an "FYI": something happened, or didn't, that may be of interest. The closest definition I can find in the docs is:
... events that do not affect the integrity of the reload operation
which is from the sql_notes server variable, one perhaps not often used outside of mysqldump.
Trawling through the MySQL source code, looks like Sql_Condition::SL_NOTE annotates warnings of this level. There are a few, but they are mostly as you'd expect for non-impactful information:
Event already exists
Table already exists
Query '%s' rewritten to '%s' by a query rewrite plugin
Password set
Sadly, I would have expected the code docblock to give a little more information about them, but it doesn't:
class Sql_condition {
public:
/**
Enumeration value describing the severity of the condition.
*/
enum enum_severity_level { SL_NOTE, SL_WARNING, SL_ERROR, SEVERITY_END };
This might warrant a documentation bug report to MySQL team.
Interestingly, MariaDB has this to say:
A note is different to a warning in that it only appears if the sql_notes variable is set to 1 (the default), and is not converted to an error if strict mode is enabled.
My takeaway from that, in Maria and possibly by extension MySQL: notes are warnings, but ones that can be ignored because no data-loss or side-effect is described.
We're running MySQL 5.5.47 on a number of Debian servers. On some of them, we're seeing the following strange behavior:
mysql> set #TKEY:='ARDARD:fae590c4.ffa2.11e5.a318.0cc47a39aeb4-1460351116';
mysql> select replace(substring_index(substring_index(#TKEY,':',-1),'-',1), '.','-') as guid;
+--------------------------------------+
| guid |
+--------------------------------------+
| fae5a2.1--0cc47a 9ae47a 9aeb4a 9aeb4 |
+--------------------------------------+
This is supposed to extract the middle part of #TKEY (between the : and -) and replace all the periods with hyphens. Where are the spaces coming from? Other parts of the result seem to be jumbled up: 9aeb4 has been duplicated, a2.1 has been shifted left.
This doesn't happen if I assign the substring_index to an intermediate variable.
mysql> set #temp = substring_index(substring_index(#TKEY,':',-1),'-',1);
mysql> select replace(#temp, '.', '-') as guid;
+--------------------------------------+
| guid |
+--------------------------------------+
| fae590c4-ffa2-11e5-a318-0cc47a39aeb4 |
+--------------------------------------+
This only happens on our production servers. I can't reproduce it on our development server or sqlfiddle. I compared all the server variables, and there are no differences that look like they should affect the behavior of string functions (there were initially some differences in character set and collation variables, but I changed the dev server to match the production server and still couldn't replicate the error.
On another production server running MySQL 5.5.41 I get a slightly different wrong result:
mysql> select replace(substring_index(substring_index(#TKEY,':',-1),'-',1), '.','-') as guid;
+--------------------------------------+
| guid |
+--------------------------------------+
| fae590c4-ffa2-11e5-a318-0cc47a 9aeb4 |
+--------------------------------------+
This is correct except that there's a space in place of of the last 3.
Can anyone explain this? Is it just a MySQL bug? I couldn't find anything at bugs.mysql.com.
This appears to be a bug that was fixed in MySQL 5.6.5. There's a somewhat similar bug report regarding LOWER(SUBSTRING_INDEX(...)). It was closed with the comment:
Noted in 5.6.5 changelog.
The result of SUBSTRING_INDEX() could be missing characters when used
as an argument to conversion functions such as LOWER().
I suspect the underlying cause is pointer misuse resulting in buffer overflow and undefined behavior. Hopefully I haven't corrupted any long-lived memory in the server.
Ok, so I've spent the morning trying to change the default collation on my XAMPP setup.
Here's the problem: I'm using Format() in a view, to convert a double into a string
CREATE VIEW `test` AS
SELECT
Format(some_data_table.double_number,0) AS string_result
FROM some_data_table;
When I look at the returned column, its showing as utf8mb4_general_ci.
I've tried all manner of settings in my.ini and phpMyAdmin's config.inc.php
to no avail.
As a last resort, I'm prepared to add the collation parameter to view.
I'd be grateful for any tested solution
Ok - i'm going to post my own answer for anyone else who lands here:
(i had seen this somewhere else, but didn't trust it a t the time because there was no explanation).
When the SQL Format() turns a number into a string, it uses the variable character_set_results.
PMA's Variables Tab was showing this as "utf8" but then on a line below, it was saying (session value) = utf8mb4.
So i was aware that PMA was overriding the server default.
My real problem was that I could find no way to change this override - either by using the [mysqld] skip-character-set-client-handshake setting.. or by editing the php.config.inc file.
Today I had a breakthrough.. I established that if I used the same PMA to connect to and older MySQL server, the problem did not occur.
This suggested to be that PMA was forcing utf8mb4 on newer (capable) servers, but not older ones.
I did a text search of phpmyadmin for the string 'mb4' and found the following code in the class: phpMyAdmin/libraries/DatabaseInterface.class.php
// Skip charsets for Drizzle
if (!PMA_DRIZZLE) {
if (PMA_MYSQL_INT_VERSION > 50503) {
$default_charset = 'utf8mb4';
$default_collation = 'utf8mb4_general_ci';
} else {
$default_charset = 'utf8';
$default_collation = 'utf8_general_ci';
}
the PMA_MYSQL_INT_VERSION > 50503 seems to fit with my theory about older mysql versions, so i've backed up the file and edited the class replacing utf8mb4 with utf8 in this function.
phpMyAdmin is now showing what i want in its variables tab, and the Format() function is now returning what i expect.
(I won't give you a tested solution without a failing test case.)
Here's a possible explanation:
mysql> SELECT FORMAT(2e7, 0);
+----------------+
| FORMAT(2e7, 0) |
+----------------+
| 20,000,000 |
+----------------+
But you are working in a "locale" where the "thousands separator" is ., not ,.
The solution has nothing to do with COLLATION. Instead, look at the arguments to FORMAT().
mysql> SELECT FORMAT(2e7, 0, 'de_DE');
+-------------------------+
| FORMAT(2e7, 0, 'de_DE') |
+-------------------------+
| 20.000.000 |
+-------------------------+
I am guessing that MS Access and MySQL are assuming different "Locales", hence stumbling over the thousands separator, and possibly other differences.
References on Locale:
http://dev.mysql.com/doc/refman/5.7/en/locale-support.html
http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_lc_time_names
I'm using Mysql's command-line client in Screen/Tmux, from Bash in OSX's Terminal.app.
When using arrow-up to re-display a previously run query that spanned more than on line, AND when the cursor is on the very last line of the Terminal, the command in mysql's command history gets 'truncated', or cut off. This never happens when I use the same tools on my Ubuntu workstation
Here's a visual representation of what happens:
Typing some query; nothing wrong here.
+-------------------------------------------+
|mysql> |
|mysql> |
|mysql> |
|mysql>select * from tables where legs = 4 a|
|nd colour = 'green'; |
+-------------------------------------------+
Run it, results are displayed:
+-------------------------------------------+
|| 2 | ....... | ..... | |
|+---+---------+-------+ |
| x rows in set (0.00 sec) |
| |
|mysql> |
+-------------------------------------------+
Hitting [arrow-up] to re-display last query leaves me with:
+-------------------------------------------+
|| 2 | ....... | ..... | |
|+---+---------+-------+ |
| x rows in set (0.00 sec) |
| |
|nd colour = 'green'; |
+-------------------------------------------+
Hit [arrow-up] again, I get:
+-------------------------------------------+
|| 2 | ....... | ..... | |
|+---+---------+-------+ |
| x rows in set (0.00 sec) |
|mysql>select * from tables where legs = 4 a|
|nd colour = 'green'; |
+-------------------------------------------+
Could the be solved by changing a setting? Or is it a bug in Mysql's client?
Software versions:
OSX 10.7.3
Terminal Version 2.2.2 (303)
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin11)
mysql Ver 14.14 Distrib 5.5.19, for osx10.7 (i386) using readline 5.1
Screen version 4.00.03 (FAU) 23-Oct-06
tmux 1.6
You have a few options I can think of to make your life easier in this regard:
readline commands combined with mysql options:
readline accepts commands similar to basic emacs commands (can be set to vi as well), or example CTRL-a returns you to the start of a line.
this combined with set horizontal-scroll-mode On, a readline that you set in ~/.inputrc, which allows you to get your input in 1 straight line, putting your cursor at the very end. Combine it with CTRL-a to immediately jump to the beginning and it's quite convenient.
~/.inputrc:
$if Mysql
set horizontal-scroll-mode On`
# uncomment the commands below to use vi keybindings
#set keymap vi
#set editing-mode vi
$endif
(some systems, OSX 10.5 for certain I believe use libedit instead of readline, in which case you need to put it all in ~/.editrc, if you're not sure about your system issue the mysql --version command )
To look for commands you issued you also have CTRL-r, which allows you to type in a term and your history will be searched for the last occurence.
interesting commands are:
CTRL-P go to the Previous command in your history
CTRL-N go to the Next command in your history
CTRL-R Reverse-search through your history
CTRL-S Search forward through your history
CTRL-A Move the cursor to the beginning of the line
CTRL-E Move the cursor to the end of the line
CTRL-W delete a Word backwards
ALT-D delete a word forwards
CTRL-F move the cursor Forward 1 character
CTRL-B move the cursor Backward 1 character
ALT-F move the cursor Forward 1 word
ALT-B move the cursor Backward 1 word
ALT-_ undo
Depending on your shell and the underlying they might not all work or be intercepted though. For example on Konsole, which I use on kde, I had to disable flow-control in advanced settings to allow for CTRL-s amongst others.
Finally mysql also gives you the \e command which allows you to edit your commands in your general file editor, if vi or emacs isn't your thing, try nano, it's easy and works well. The main disadvantage of using this is that when scrolling up newlines are ignored bu tabs and spaces aren't. It's a unix only thing but OS X should do fine there, can't check since I don't own any Apple computers, sorry. :)
To more easily use this command you could put a readline string macro in ~/.inputrc
e.g. Control-o: "\\e;\n" would bind CONTROL-o to \e; followed by enter for instant execution. (look at the Keybindings Section)
use an alternate shell:
such as altSQL: it gives syntax colouring, nice history scrolling and some other niceties, big bonus is that you have the source so you can adapt what you want.
drop the shell and go GUI:
Finally I'd like to plug the nice MySQL workbench to work on your databases, it's cross-platform, free and in my humble opinion a nice tool to work with.
I realise it's not a perfect solution and each have advantages and drawbacks but I hope this has helped you along somewhat.
We recently switched to an RDS instance and noticed that bunch of our database tasks were getting triggered 4 hours earlier than needed. On investigating further, the problem is caused by the default time-zone setting (UTC) on the RDS instance. Since this setting can not be altered, we would like to fix the issue on the code level globally across all our applications using this database instance. I tried to set the time-zone on the db instance I create to 'US/Eastern' by using
set GLOBAL time_zone = 'US/Eastern'" OR
set time_zone = 'US/Eastern'"
But that generates an error "Database error: Unknown or incorrect time zone: 'US/Eastern'"
What do you think I am doing wrong here? Does anyone has used any other solutions ?
Unfortunately it's not possible to set the default_timezone in the RDS DB ParameterGroups so your attempt was the right direction already.
$ rds-describe-db-parameters default | grep "time_zone"
DBPARAMETER default_time_zone engine-default string static false
To set the global value via SET GLOBAL you need to have the SUPER privilege which is not granted to you as a RDS user.
The only way to set the time_zone is on a per-connection basis
mysql> SET time_zone = timezone;
On my machines I've tried US/Eastern successfully but I got a quite old generation running.
To determine the timezones you have available log into your box
mysql -h yourboxhost.rds.amazonaws.com -u <youruser> -p
and type
mysql> SELECT * FROM mysql.time_zone_name;
You should get a list of installed and valid timezone names you can set on your instance
+----------------------------------------+--------------+
| Name | Time_zone_id |
+----------------------------------------+--------------+
| Africa/Abidjan | 1 |
| Africa/Accra | 2 |
| Africa/Addis_Ababa | 3 |
| Africa/Algiers | 4 |
| Africa/Asmara | 5 |
| Africa/Asmera | 6 |
| Africa/Bamako | 7 |
| Africa/Bangui | 8 |
| Africa/Banjul | 9 |
| Africa/Bissau | 10 |
| Africa/Blantyre | 11 |
| Africa/Brazzaville | 12 |
| Africa/Bujumbura | 13 |
| Africa/Cairo | 14 |
etc...
You have to set the time_zone each time you connect to your database server
For example if you use the php Mysqli extension you can do this
$mysqli = mysqli_init();
mysqli_options($mysqli,MYSQLI_INIT_COMMAND,"SET time_zone = 'Africa/Brazzaville'" );
mysqli_real_connect($mysqli,$host, $user, $pass,$dbName) or die ('Unable to connect');
Otherwise just manually ( in terms of let your database connector do it ) execute the SET time_zone = '<YOUR_DESIRED_TIMEZONE>' Query right after you've connected to your database
The time_zone setting of RDS database instances can now be modified: https://aws.amazon.com/de/premiumsupport/knowledge-center/rds-change-time-zone/
I did the following steps, So that I could change the timezone
login to RDS and Create New Parameter Group.
Edit the newly created Parameter Group
Set timezone Ex:Asia/Calcutta and Save Changes
Modify RDS instance, change DB's Parameter Group to newly created parameter group
Save And Reboot RDS instance
tldr;
Create a "shared" schema that all your users have EXECUTE access to, create a SPROC that modifies the session timezone and modify the init_connect MySQL parameter to call it.
As Ryan Weir pointed out in his excellent answer in a duplicate question this should probably be avoided if possible. If, however, you are like me and want to implement it for the sake of convenience and sanity then I took Ryan's solution and made a few modifications.
If you have multiple users setup in MySQL with varying permissions then simply putting the sproc in the mysql schema might have problems. To solve this I created a new schema called "shared" and gave all my users EXECUTE access to this schema. I then created the following stored procedure.
DROP PROCEDURE IF EXISTS shared.store_time_zone;
CREATE PROCEDURE shared.`store_time_zone`()
IF NOT (POSITION('rdsadmin#' IN CURRENT_USER()) = 1) THEN
SET SESSION time_zone = 'US/Pacific';
END IF;
I prefer to set 'US/Pacific' to handle daylight savings but you should test this to make sure your MySQL instance recognizes it first. Just execute the following query SET SESSION time_zone = 'US/Pacific'; to make sure it works. To look up your timezone execute SELECT * FROM mysql.time_zone_name;
At this point I recommend testing the permissions before you go modifying the paramter group and potential break everything. Simply connect to the DB (preferably with a user that has low level permissions and/or is commonly used) and execute the following queries.
CALL shared.store_time_zone;
select now();
Hopefully you didn't get any errors and the correct time showed up.
Next you will need to modify the init_connect parameter in the DB Parameter Group that your RDS instance is using. You can do this in the RDS web console, through the API or the command line utility. If you use the command line it will look like this:
$ rds-modify-db-parameter-group PARAMGROUP --parameters "name=init_connect, value='CALL shared.store_time_zone', method=immediate"
If you do it through the web console then you just need to change the value of init_connect.
CALL shared.store_time_zone
Go back to your RDS instance in the web console and scroll the details pane down to the DB Parameter Group. It should say something like (applying) or (in-sync). Once it is (in-sync) go test everything out to make sure there are no problems.
If at this point you run into problems and need to roll things back then I recommend setting the init_connect value to something harmless like:
SET SESSION time_zone = '-00:00';
Setting it back to blank is impossible to do from the web console. See this thread for more details on why one can't restore the empty value for the DB parameter
#Thomas Paine's solution works for me except I had to user user() instead of current_user() as inside the context of init_connect current_user() returns the master RDS user. (By master I do not mean rdsadmin which is the real root user but the user created with the DB instance with most privileges.)