all tables should have a primary key
that will give them an index automatically
then, for related tables, declare an index for each foreign key (which, unless you're using innodb, you don't need to bother declaring as a foreign key) -- the foreign key being the column in the related table that connects to the first table's primary key
thus, every column in all of your ON conditions will have an index
then, consider an index for a column such as dmasterfecha which is used in the WHERE clause and has good selectivity -- imasterclie, on the other hand, may not have good selectivity
by good selectivity, i mean there is a good chance that the optimizer will decide to use the index because it reduces the number of potential rows to be returned
for example, if you had a large table of people, and you had a column for gender, with 1=male and 2=female, then fully half the table will have each value, so that does not provide good selectivity
since the database requires two reads, one for the index and one for the row, if you access half the table that way, there's not much point, so a good optimizer will ignore an index on gender
rudy
http://r937.com/