No, running composer update will not – by itself – result in any changes to your database.
When you run composer update, all that happens is that Composer downloads updated versions for all your installed packages (i.e. Craft, plugins and other dependencies), before writing a manifest of your currently installed packages to the composer.lock file. Full stop; Craft isn't actually involved in this process at all.
However, sometimes an updated version of Craft (or a plugin) might need to change something in the database, in order to function. This is called a "migration", and is distributed with the package in question as a "migration file", containing the database queries necessary to perform the update that the new version of the package needs. In terms of updating core code or plugins, running these migrations is the only thing that will end up actually updating your database. You do have to run them at some point, because if there are pending migrations on your site's file system (i.e. migrations that have been downloaded but not run yet) your site will be unavailable until those migrations have been run (important – note that if you're updating Craft or a plugin through the Control Panel and not using the command line/Composer directly, Craft will attempt to auto-run any migrations for you, after Composer finishes downloading the new packages).
There are two ways to run pending migrations:
- Visit the control panel in a browser, and click the prompt(s)
Execute the following from your command line (this should be run from the root directory for your project, i.e. where your composer.json file resides):
./craft migrate/up
The above command is safe to run even if there aren't actually any migrations pending, so if you're writing some sort of update/sync script, it could easily be tacked on at the end to make sure that any pending migrations that might be included with the updated code, are run (if you sync up the database instead, this won't be necessary as long as you've run the migrations locally).
In addition to the above – while your strategy for keeping Composer dependencies on the live server updated certainly works, it seems a bit unnecessary and/or convoluted to have to sync the database from local to production. I'd advise to either just run the migrate command in case there are migrations, or even follow what is generally considered the best practice for dealing with Composer dependencies: don't commit the actual dependencies (i.e. your /vendor folder) to version control, only the composer.lock file, and run composer install on the server, after the latest version has been deployed. Here's how a very simple deploy script could look:
cd /path/to/host/root
git pull origin production
composer install --no-interaction --prefer-dist --optimize-autoloader
./craft migrate/up
echo "" | sudo -S service php7.0-fpm reload
