This team has noticed a slight degradation in performance since the 7.1.1.4 upgrade and feels that the indexing that was created in the upgrade either failed or is having an adverse effect on their performance due to the manual indexing they created last year.

It is entirely possible that some of the indexes in use are duplicates - i.e., that you now have two different indexes that are indexing the same table.column. This would degrade performance, having to maintain two indexes on disc for a single column.

What indexing specifically is 7.1.1.4 creating

What was indexed: every field constrained by a foreign key (that wans't somehow otherwise being indexed). Only MySQL indexes columns as part of its foreign key constraint mechanism; every other database simply notes the requirement. NOT indexing foreign-keyed columns causes delays and deadlocks if the dataset gets large enough.

Having said that, here's a complete list.

Sorted as such: 'Name of Index' -> { 'Table being indexed' -> }.

'bfpatchidx0' -> { 'bf_messages' -> }
'bfpatchidx1' -> { 'bf_messages' -> }
'bfpatchidx2' -> { 'bf_accgrp_user' -> }
'bfpatchidx3' -> { 'bf_jobcount' -> }
'bfpatchidx4' -> { 'bf_jobcount' -> }
'bfpatchidx5' -> { 'bf_jobcount' -> }
'bfpatchidx6' -> { 'bf_jobcount' -> }
'bfpatchidx7' -> { 'bf_versions' -> }
'bfpatchidx8' -> { 'bf_builds' -> }
'bfpatchidx9' -> { 'bf_builds' -> }
'bfpatchidx10' -> { 'bf_builds' -> }
'bfpatchidx11' -> { 'bf_builds' -> }
'bfpatchidx12' -> { 'bf_builds' -> }
'bfpatchidx13' -> { 'bf_builds' -> }
'bfpatchidx14' -> { 'bf_builds' -> }
'bfpatchidx15' -> { 'bf_builds' -> }
'bfpatchidx16' -> { 'bf_builds' -> }
'bfpatchidx17' -> { 'bf_builds' -> }
'bfpatchidx18' -> { 'bf_scopes' -> }
'bfpatchidx19' -> { 'bf_scopes' -> }
'bfpatchidx20' -> { 'bf_classes' -> }
'bfpatchidx21' -> { 'bf_classes' -> }
'bfpatchidx22' -> { 'bf_classes' -> }
'bfpatchidx23' -> { 'bf_env' -> }
'bfpatchidx24' -> { 'bf_env' -> }
'bfpatchidx25' -> { 'bf_enventry' -> }
'bfpatchidx26' -> { 'bf_enventry' -> }
'bfpatchidx27' -> { 'bf_buildenv' -> }
'bfpatchidx28' -> { 'bf_buildenventry' -> }
'bfpatchidx29' -> { 'bf_buildenventry' -> }
'bfpatchidx30' -> { 'bf_buildenventry' -> }
'bfpatchidx31' -> { 'bf_projects' -> }
'bfpatchidx32' -> { 'bf_projects' -> }
'bfpatchidx33' -> { 'bf_projects' -> }
'bfpatchidx34' -> { 'bf_projects' -> }
'bfpatchidx35' -> { 'bf_projects' -> }
'bfpatchidx36' -> { 'bf_projects' -> }
'bfpatchidx37' -> { 'bf_projects' -> }
'bfpatchidx38' -> { 'bf_projects' -> }
'bfpatchidx39' -> { 'bf_results' -> }
'bfpatchidx40' -> { 'bf_results' -> }
'bfpatchidx41' -> { 'bf_results' -> }
'bfpatchidx42' -> { 'bf_results' -> }
'bfpatchidx43' -> { 'bf_results' -> }
'bfpatchidx44' -> { 'bf_results' -> }
'bfpatchidx45' -> { 'bf_results' -> }
'bfpatchidx46' -> { 'bf_results' -> }
'bfpatchidx47' -> { 'bf_results' -> }
'bfpatchidx48' -> { 'bf_results' -> }
'bfpatchidx49' -> { 'bf_results' -> }
'bfpatchidx50' -> { 'bf_cron' -> }
'bfpatchidx51' -> { 'bf_cron' -> }
'bfpatchidx52' -> { 'bf_cron' -> }
'bfpatchidx53' -> { 'bf_cron' -> }
'bfpatchidx54' -> { 'bf_cron' -> }
'bfpatchidx55' -> { 'bf_cron' -> }
'bfpatchidx56' -> { 'bf_servers' -> }
'bfpatchidx57' -> { 'bf_servers' -> }
'bfpatchidx58' -> { 'bf_servers' -> }
'bfpatchidx59' -> { 'bf_servers' -> }
'bfpatchidx60' -> { 'bf_servers' -> }
'bfpatchidx61' -> { 'bf_servers' -> }
'bfpatchidx62' -> { 'bf_servertest' -> }
'bfpatchidx63' -> { 'bf_collectorentry' -> }
'bfpatchidx64' -> { 'bf_selector' -> }
'bfpatchidx65' -> { 'bf_selector' -> }
'bfpatchidx66' -> { 'bf_selectorentry' -> }
'bfpatchidx67' -> { 'bf_selectorentry' -> }
'bfpatchidx68' -> { 'bf_steps' -> }
'bfpatchidx69' -> { 'bf_steps' -> }
'bfpatchidx70' -> { 'bf_steps' -> }
'bfpatchidx71' -> { 'bf_steps' -> }
'bfpatchidx72' -> { 'bf_steps' -> }
'bfpatchidx73' -> { 'bf_steps' -> }
'bfpatchidx74' -> { 'bf_templates' -> }
'bfpatchidx75' -> { 'bf_templates' -> }
'bfpatchidx76' -> { 'bf_templatelang' -> }
'bfpatchidx77' -> { 'bf_users' -> }
'bfpatchidx78' -> { 'bf_users' -> }
'bfpatchidx79' -> { 'bf_sessions' -> }
'bfpatchidx80' -> { 'bf_filterentry' -> }
'bfpatchidx81' -> { 'bf_filterevents' -> }
'bfpatchidx82' -> { 'bf_notes' -> }
'bfpatchidx83' -> { 'bf_semaphores' -> }
'bfpatchidx84' -> { 'bf_semaphores' -> }
'bfpatchidx85' -> { 'bf_semaphores' -> }
'bfpatchidx86' -> { 'bf_buildreg' -> }
'bfpatchidx87' -> { 'bf_bom' -> }
'bfpatchidx88' -> { 'bf_interfacerelations' -> }
'bfpatchidx89' -> { 'bf_interfacecategories' -> }
'bfpatchidx90' -> { 'bf_interfacesections' -> }
'bfpatchidx91' -> { 'bf_interfacesections' -> }
'bfpatchidx92' -> { 'bf_interfacedata' -> }
'bfpatchidx93' -> { 'bf_interfacedata' -> }
'bfpatchidx94' -> { 'bf_interfacedata' -> }
'bfpatchidx95' -> { 'bf_interfacedata' -> }
'bfpatchidx96' -> { 'bf_interfacenotices' -> }
'bfpatchidx97' -> { 'bf_interfacetemplateenv' -> }
'bfpatchidx98' -> { 'bf_interfacetemplateentry' -> }
'bfpatchidx99' -> { 'bf_preferences' -> }
'bfpatchidx100' -> { 'bf_stepcmd' -> }
'bfpatchidx101' -> { 'bf_stepcmd' -> }
'bfpatchidx102' -> { 'bf_stepcmd' -> }
'bfpatchidx103' -> { 'bf_authconfig' -> }
'bfpatchidx104' -> { 'bf_ldap' -> }
'bfpatchidx105' -> { 'bf_uifilters' -> }
'bfpatchidx106' -> { 'bf_bom_manifests' -> }
'bfpatchidx107' -> { 'bf_filestore' -> }
'bfpatchidx108' -> { 'bf_reflect' -> }
'bfpatchidx109' -> { 'bf_reflect' -> }
'bfpatchidx110' -> { 'bf_report' -> }
'bfpatchidx111' -> { 'bf_report_field' -> }
'bfpatchidx112' -> { 'bf_report_field' -> }
'bfpatchidx113' -> { 'bf_report_filter' -> }
'bfpatchidx114' -> { 'bf_datasource' -> }
'bfpatchidx115' -> { 'bf_datasource' -> }
'bfpatchidx116' -> { 'bf_dataset' -> }
'bfpatchidx117' -> { 'bf_dataset' -> }
'bfpatchidx118' -> { 'bf_column' -> }
'bfpatchidx119' -> { 'bf_security_global' -> }
'bfpatchidx120' -> { 'bf_security_global' -> }
'bfpatchidx121' -> { 'bf_security_global' -> }
'bfpatchidx122' -> { 'bf_security_global' -> }
'bfpatchidx123' -> { 'bf_security_global' -> }
'bfpatchidx124' -> { 'bf_security_global' -> }
'bfpatchidx125' -> { 'bf_security_global' -> }
'bfpatchidx126' -> { 'bf_security_global' -> }
'bfpatchidx127' -> { 'bf_security_global' -> }
'bfpatchidx128' -> { 'bf_security_global' -> }
'bfpatchidx129' -> { 'bf_security_sso' -> }
'bfpatchidx130' -> { 'bf_security_context' -> }
'bfpatchidx131' -> { 'bf_security_pwcrypt' -> }
'bfpatchidx132' -> { 'bf_security_ssl' -> }
'bfpatchidx133' -> { 'bf_security_ssl' -> }
'bfpatchidx134' -> { 'bf_eventarg' -> }
'bfpatchidx135' -> { 'bf_eventregfilt' -> }
'bfpatchidx136' -> { 'bf_plugin_cfg_data' -> }
'bfpatchidx137' -> { 'bf_license' -> }

how can we determine if there is a problem with the indexing this user currently has ended up with

If your DBO knows which indexes he created, he can compare that list to this one and find out which (if any) are duplicate indexes.

and do you have suggestions for corrective actions.

It may be easier and faster to simply create a new database, and copy all of the data from the old one into the new one. Or better yet, create a new database, import the projects you're working with over to it, and run them - see if this performs better than what you had before, THEN decide what you're eventually going to do.

But that all depends on whether or not your DBO knows what he or she did. If so, simple comparison and removal of duplicate indexes (again, if any exist) would probably be your best bet.