MySQL User password settings modification and permission assignment

My MySQL is installed in C:\mysql

One, change the password the first way: 1, the situation before the change root without password c:\mysql\bin>mysqladmin-u root password "Your password" 2, the change before the root password, if 1234 C:\mysql\bin>mysqladmin-u root-p123456 Password "Your password" NOTE: The changed password cannot be enclosed in single quotes, double quotation marks, or no quotation marks   second way: 1, C:\My Sql\bin>mysql-uroot-p password log in as root 2, mysql>use mysql Select database 3, mysql>update user set Password=password (' Your password ') W　　Here user= ' root '; 4, Mysqlflush privileges; Reload Permissions Table   Second, user rights set 1, as root (also available to other users) login 2, create a test user, the password is test, and can only manipulate the picture database command mysql>grant all on p The syntax for the icture.* to test identified by "test";  Grant statement looks like this: Grant privileges (columns) on-what-user identified by "Password" with Grant OPTION    to use this statement, you need to fill in the following section:  privileges permissions granted to the user, the following table lists the permission specifiers that are available for the GRANT statement:  permission specifier 　　Permissions allowed actions   ALTER modify tables and indexes   CREATE DATABASE and tables   Delete delete existing records in table   drop discard (delete) database and table   index create or Discard indexes   insert new rows into table   REFERENCE not used   Select to retrieve records in table   UPDAte modify existing table records   file read or write files on server   PROCESS view thread information executed on server or kill thread   RELOAD overload authorization table or empty log, host cache, or table cache.   SHUTDOWN shut down server   All, all privileges synonyms   USAGE Special "No permissions" right   above table shows permissions specified in the first group applies for databases, tables, and columns , the second set of administrative permissions. Generally, these are relatively strictly authorized because they allow the user to affect the operation of the server. The third set of permissions is special, all means "all permissions," and Uasge means no permissions, that is, creating the user, but not granting permissions.   Columns permissions apply the column, which is optional, and you can only set column-specific permissions. If the command has more than one column, you should separate them with commas.    what level of permission to use. Permissions can be global (for all databases and all tables), a specific database (for all tables in a database), or a specific table. You can specify a columns sentence by specifying that the permission is column-specific.   User privilege, which consists of a user name and host name. In MySQL, you not only specify who can connect, but also where to connect. This allows you to connect two users of the same name from different places. MySQL allows you to differentiate between them and give permission independently of each other. A user name in MySQL is the user name you specify when you connect to the server, which does not have to be associated with your UNIX login or Windows name. By default, if you do not explicitly specify a name, the client program will use your login name as the MySQL user name. It's just a convention. You can change the name to nobody in the authorization form, and then perform the action that requires superuser privileges on the nobody connection.    password gives the user a password, which is optional. If you do not specify a identified by clause for a new user, the user does not assign a password (unsafe). For existing users, any password you specify will replace the old password. If you do not specify a password, the old password remains the same, and when you use identified by, the password string uses the literal meaning of the password instead, grant will encode the password for you, and do not use the PASSWORD () function with set PASSWORD. The    with GRANT option clause is optional. IfYou include it, and the user can grant permissions to other users through the GRANT statement. You can use this clause to give the ability to authorize other users.   NOTE: The user name, password, database, and table name are case-sensitive in the authorization table record, and the hostname and column name are not.    in general, you can identify the kind of grant statement by asking a few simple questions:  who can connect and connect from there?   What level of permissions should users have, and what do they apply to?   Should users be allowed to manage permissions?    Some examples are discussed below.    1.1 who can connect and connect from there?   You can allow a user to connect from a specific or a range of hosts. There's an extreme if you know demotion from a host connection, you can restrict permissions to a single host:  grant all on samp_db.* to [email protected] identified by "Ruby" GRANT AL L on samp_db.* to [email protected] identified by "quartz"    (samp_db.* means "All tables of the samp_db database") Another extreme is that You may have a user Max who travels frequently and needs to be able to connect from hosts around the world. In this case, you can allow him to connect no matter where it is: GRANT all on samp_db.* to [email protected]% identified by "Diamond"   "%" character character wildcard action, and like mode The meaning of the match is the same. In the above statement, it means "any host". So Max and [email protected]% are equivalent.　　This is the simplest way to build a user, but it is also the least secure. Where you can allow a user to access from a restricted host collection. For example, to allow Mary to connect from any host in the snake.net domain with a%.snake.net host specifier: GRANT all on samp_db.* to [email protected] identified by " Quartz ";  If you like, the host part of the user identifier can be given with an IP address instead of a hostname. You can specify an IP address or an address that contains a pattern character, and, from MySQL 3.23, you can alsoTo specify the IP number that has a netmask that indicates the number of bits used for the network number:  GRANT all on samp_db.* to [email protected] identified by "Ruby"   GRANT all on samp_db.* to [email protected]% identified by ' quartz '   GRANT all on samp_db.* to [Email protected]/17 ID Entified by "Ruby"    The first example indicates the specific host from which the user can connect, the second specifies the IP schema for the class C subnet 192.168.128, and in the third statement, the 192.168.128.0/　　　17 Specify a 17-bit network number and match the IP address that has 192.168.128 Header 17 bits.　　1.2 What level of permissions should users have and what should they apply to? You can authorize different levels of permissions, and global permissions are the most powerful because they apply to any database. To make Ethel a super user that can do anything, including the ability to authorize other users, issue the following statement:  GRANT all on *. * to [email protected] identified by "coffee" with GRAN The *. * in the T option  on clause means "all databases, all tables." From security considerations, we specify that Ethel can only be connected from local.　 　Restricting a host that a superuser can connect to is usually sensible because it restricts the host that tries to crack the password. Some permissions (FILE, PROCESS, Reload, and shutdown) are administrative permissions and can only be authorized with the "On * *" global permission specifier. If you want, you can authorize these permissions without authorizing the database permissions. For example, the following statement sets a flush user, and he can only issue flush statements. This may be useful in administrative scripts that you need to perform such as emptying the log: GRANT RELOAD on * * to [email protected] identified by "Flushpass"    generally, you want to authorize the Tube Because users who have them can affect the operation of your server. Database-level permissions apply to all tables in a particular database, and they can be granted by using the on db_name.* clause: &NBSp Grant all on samp_db to [email protected] indetified by ' Rock ' grant Select on samp_db to [email protected]% IND Etified by "Rock"    the first statement authorizes bill to samp_db all tables in the database, the second creates a strictly restricted user ro_user (read-only user) and can access all tables in the SAMP_DB database only. But only read, that is, the user can only issue SELECT statements.   You can list the various permissions that are granted at the same time. For example, if you want users to be able to read and modify the contents of an existing database, but cannot create a new table or delete a table, grant these permissions as follows: Grant Select,insert,delete,update on samp_db to [email  Protected] Indetified by "Rock"   for more sophisticated access control, you can authorize on individual tables, or even on each column of a table. Column-specific permissions are useful when you want to hide portions of a table from the user, or if you want a user to be able to modify only specific columns. such as:  Grant Select on Samp_db.member to [email protected] indetified by "Rock" GRANT Update (expiration) on Samp _db. Member to [email protected]  the first statement grants read access to the entire member table and sets a password, and the second statement adds the update permission when only the expiration column. There is no need to specify the password again because the first statement is already specified.   If you want to grant permissions to multiple columns, specify a comma-separated list. For example, for the assistant user to increase the Update permission for the Address field of the member table, the new permission is added to the user's existing permissions by using the following statement: GRANT Update (Street,city,state,zip) on samp_db to [　 　email protected]  1.3 Should the user be allowed to manage permissions? You can allow the owner of a database to control access to the database by granting all owner permissions on the database,Specified with GRANT OPTION. For example, if you want Alicia to be able to connect from any host in the big.corp.com domain and have administrator privileges for all tables in the sales database, you can:  grant all on sales.* to [email  with the following GRANT statement: Protected]%.big.corp.com indetified by ' Applejuice ' with grant option   on effect with the GRANT OPTION clause allows you to grant access to the authority of another A user. Be aware that two users with grant permissions can authorize each other. If you give only the first user select permission, and the other user has grant plus SELECT permission, then the second user can be the first user more "powerful".   2 remove a user   to cancel a user's permission, use the REVOKE statement. The syntax of the REVOKE is very similar to the GRANT statement, except that the to is substituted with the From and has no indetifed by and with GRANT option clauses:  REVOKE privileges (columns) on the What from US The er   user section must match the user portion of the original grant statement that you want to withdraw. The privileges part does not need to be matched, you can authorize with the grant statement, and then use the REVOKE statement to revoke only partial permissions. The   REVOKE statement removes only the permission without deleting the user. Even if you revoke all permissions, the user records in the users table remain, which means the user can still connect to the server. To completely remove a user, you must explicitly delete the user record from the users table with a DELETE statement:  %mysql-u root mysqlmysql>delete from user->where user= "user_ Name "and host=" host_name "; Mysql>flush privileges;  DELETE statement deletes the user record, while the FLUSH statement tells the server to overload the authorization table. (When you use the GRANT and REVOKE statements, the table is automatically overloaded, not when you modify the authorization table directly.) ）