Risk-Minimization Guidelines For the  ROUTINES  table, the query includes the  ROUTINE_TYPE  column so that output rows distinguish whether the  DEFINER  is for a stored procedure or stored function. If the account you are searching for does not exist, any objects displayed by those queries are orphan objects. Risk-Minimization Guidelines To minimize the risk potential for stored object creation and use, follow these guidelines: •Do not create orphan stored objects; that is, objects for which the  DEFINER  attribute names a nonexistent account. Do not cause stored objects to become orphaned by dropping or renaming an account named by the  DEFINER  attribute of any existing object. •For a stored routine or view, use  SQL SECURITY INVOKER  in the object definition when possible so that it can be used only by users with permissions appropriate for the operations performed by the object. •If you create definer-context stored objects while using an account that has the  SET_USER_ID  privilege (or the deprecated  SUPER  privilege), specify an explicit  DEFINER  attribute that names an account possessing only the privileges required for the operations performed by the object. Specify a highly privileged  DEFINER  account only when absolutely necessary. •Administrators can prevent users from creating stored objects that specify highly privileged  DEFINER accounts by not granting them the  SET_USER_ID  privilege (or the deprecated  SUPER  privilege). •Definer-context objects should be written keeping in mind that they may be able to access data for which the invoking user has no privileges. In some cases, you can prevent references to these objects by not granting unauthorized users particular privileges: •A stored routine cannot be referenced by a user who does not have the  EXECUTE  privilege for it. •A view cannot be referenced by a user who does not have the appropriate privilege for it ( SELECT  to select from it,  INSERT  to insert into it, and so forth). However, no such control exists for triggers and events because they always execute in definer context. The server invokes these objects automatically as necessary, and users do not reference them directly: •A trigger is activated by access to the table with which it is associated, even ordinary table accesses by users with no special privileges. •An event is executed by the server on a scheduled basis. In both cases, if the  DEFINER  account is highly privileged, the object may be able to perform sensitive or dangerous operations. This remains true if the privileges needed to create the object are revoked from the account of the user who created it. Administrators should be especially careful about granting users object-creation privileges. 25.7 Stored Program Binary Logging The binary log contains information about SQL statements that modify database contents. This information is stored in the form of “events”  that describe the modifications. (Binary log events differ from scheduled event stored objects.) The binary log has two important purposes: •For replication, the binary log is used on source replication servers as a record of the statements to be sent to replica servers. The source sends the events contained in its binary log to its replicas, which 4754